Floating point performance issue

Jeff Kenton jkenton@tilera.com
Tue Dec 20 15:45:00 GMT 2011

On 12/20/2011 09:24 AM, Vincent Lefevre wrote:
> On 2011-12-20 14:57:16 +0100, David Brown wrote:
>> On 20/12/2011 14:43, Vincent Lefevre wrote:
>>> I disagree: the operations could be written in an order to avoid some
>>> inaccuracies (such as huge cancellations) or to emulate more precision
>>> (e.g. via Veltkamp's splitting) or to control the rounding (see some
>>> rint() implementation http://sourceware.org/bugzilla/show_bug.cgi?id=602
>>> for instance). On such code, unsafe optimizations could yield problems.
>> I guess that's why it's an option - then we can choose.
> Really, it should have never been an option since it may produce
> incorrect code. Such kinds of optimization should have only been
> enabled via pragmas, and only in a well-documented manner so that
> the developer can know how this code could be transformed (and
> only the developer should be allowed to enable such optimizations).
>> I would still say that most floating point code does not need such
>> control, and that situations where it matters are rather
>> specialised.
> I think that if this were true, there would have never been an
> IEEE 754 standard.

This argument has been going on since (or before) the IEEE 754 standard 
was approved.  Mathematical purists on one side and 
just-make-it-run-fast pragmatists on the other.  We won't solve it here.


More information about the Gcc-help mailing list