[LLVMdev] Presenting Unsafe Math Flag to Optimizer

[Stephen Canon]

On Jan 15, 2010, at 1:24 AM, Morten Ofstad wrote:

> I think the main issues are:
> 
> 1) special values (+0, -0, NaN, +Inf, -Inf) to be taken into account
> - this can be represented with an 'assume_finite' bit and an 'assume_no_signed_zero' bit

Sounds right to me.

> 2) rounding, the x86 FPU has 80 bits of internal precision, so you get inconsistent results depending
> on intermediate results being spilled or being kept in registers. One usual way of handling this is
> that any assignment in the source code will truncate to the memory representation, while intermediate
> results in an expression are allowed to be kept at 80 bits precision (i.e. frontend decides which operations must be rounded).
> - this can be represented with a 'exact_precision' bit

Does LLVM even support generating float and double arithmetic on x87?  Certainly the default should be to use SSE/SSE2 and avoid this problem entirely.  If legacy x87 codegen is supported, it would be nice to have float-store be the default behavior, and require a flag "-fnon-portable-extra-precision" or something similarly menacing to enable the other behavior.

> 3) exceptions, you might need to have the right number of exceptions triggered in the right order so basically no optimizations are allowed.
> - this can be represented with a 'trapping_math' and/or 'signaling_NaN' bit, or maybe it can be encoded as  'no_reorder' 'no_duplicate'

Some reordering should be inhibited not only by trapping math, but also by the default IEEE-754 exception handling (nonstop execution with status flags), at least when #pragma STDC FENV_ACCESS ON is active.  If the reordering affects only the order in which flags could be raised, and not which flags could be raised, then it could be allowed with the default exception handling.

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100115/6297cc14/attachment.html>