Loïc Minier wrote:
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.
Like everyone else, I'd like to see numbers.
We can, however, to some extent scope the kind of programs that will benefit. To benefit, a program must have a call to a small function that takes floating-point arguments or returns a floating-point value in an inner loop. (It must be a small function, since otherwise the parameter-passing costs will be dwarfed by the function itself.) This is a relatively rare situation, but OpenGL or the like are probably examples of where this could be important. In many cases, making the small function "inline" may be a better solution than the hardfp ABI.
Some of the examples in Dave's email can be dealt with without a completely hardfp world. For example, the ABI says nothing about calls to static helper functions within a module, so there's no reason (in principle) the compiler could not use the hardfp ABI in that situation. The same could be accomplished for a non-static function using a special attribute.