[LLVMdev] Presenting Unsafe Math Flag to Optimizer

Morten Ofstad morten at hue.no
Fri Jan 15 01:24:32 PST 2010


> This is actually really easy to do, the big issue is defining the
> 'bits' that we want to carry on each operation.  For example, I think
> it would be reasonable to have an "assume finite" bit (saying no
> nan's / inf), it would also be useful to know you can do reassociation
> etc, useful to know that you don't care about signed zero, etc.

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

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

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'

see:
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Optimize-Options.html (look 
for -ffloat-store)
http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx (Title: /fp (Specify 
Floating-Point Behavior))

- Morten
 




More information about the llvm-dev mailing list