[Linaro-dev] Discussion on new ARM hard-float port on debian-arm@

[Loïc Minier]

        Hey Dave

 Great to have you back!

On Fri, Jul 09, 2010, Dave Martin wrote:
> Regarding this discussion, I stongly advocate getting some benchmarks
> --- we should be careful about drawing conclusions like "won't be much
> of a win on A9" without some quantification.

 +1; this is just from hearsay so far.

 Would you be in a position to do them?

 Markos has the karmic rebuild of armel with hard-float ABI + sources.
 There are some rootfses up there as well.  I will share the link with
 you off-list since I'm not sure it's ok to advertize it wildly.

> For all v7 processors (A8, A9, etc.) the hardfp ABI will increase the
> register bandwidth for funtion calls.  In some cases of floating-point
> intensive code, the increase will be substantial.

 Yes; I agree, in any case, the hard-floating point will be superior, we
 don't know how much.
   What I meant to express is that Linaro didn't go for a hardfp port
 because the wins weren't obvious over the (large) time investment +
 maintenance commitment, and it seemed that by the time we would get
 there, Cortex-A9s would be common and the wins would be limited.

 Now if we were to have benchmarks, the story might be entirely
 different indeed.

> One particular issue we have is that the toolchain cannot easily
> handle intermixing of multiple ABIs, so it isn't straightforward to
> use a different ABI (hard) internally to a library or shared object
> compared with the ABI (softfp) used at the public interface.  This
> means that some libs which may get significant benefit from the hard
> fp ABI to accelerate internal function calls (such as libm, as well as
> any computational library) cannot be built using the hard fp ABI
> internally without doing significant work, unless the whole system is
> built with hard fp.  It's certainly not something we can achieve by
> simply using dififerent build options for targeted libraries, as can
> be done for NEON optimisations for example.

 I think we either have a Debian (and an Ubuntu) hard-float port or we
 don't; once we have it, everything is available with hard-float, and we
 will probably shift our focus on that.  If the cost is too high, then
 we will stay with the armel port and try to rip the most benefits out
 of it, building vfp versions of the libs (softfp).  Perhaps we need to
 fix the toolchain to be more agressive in softfp mode (especially when
 combined with -Bsymbolic-functions), or perhaps we need to rework key
 libraries to use hardfp but keep a soft-float interface as you say.

> Judging how much these changes will improve the performance of
> real-world code, and how the improvement compares on A9 versus A8, is
> difficult without doing some benchmarking though.

 You speak the truth!   Thanks a lot for your comments

-- 
Loïc Minier