This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: ARM Cortex-A8 and floating point performance


On 16/06/2010 17:09, Andrew Pinski wrote:


On i?86 we have -mfpmath={sse,x87}, I suppose you could add
-mfpmath=neon for arm (properly conflicting with -mfloat-abi=hard
and requiring neon support).

Except unlike sse, neon does not fully support IEEE support. So this should only be done with -ffast-math :). The point that it is slow is not good enough to change it to be something that is wrong and fast.


How relevant is full IEEE support? I would imagine that only a tiny minority of programs actually need it. But I would also imagine that the great majority of programs are compiled without -ffast-math, even though that would be perfectly good for them, and generate smaller and faster code on almost all platforms.


So if -ffast-math were the default, would many people actually see wrong code? Obviously such a change could not be done arbitrarily - as you say, slow code is better than wrong code. It would have to be done through stages for successive gcc releases of adding a "-fieee-math" flag (synonymous with -fno-fast-math), and giving warning messages if neither "-fieee-math" or "-ffast-math" were specified, before it could be changed. And it would only apply to the -std=gnu... standards. But the end result is that the majority of users would generate faster code.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]