[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