On Jan 14, 2010, at 2:01 AM, Duncan Sands wrote:> Hi Bill, > >> The current implementation of the "allow unsafe math" option is to >> specify it via the TargetOptions object. However, this prevents the >> target-independent optimizer from using it. Are there any opinions >> (ha!) on how this could be achieved in a nice clean manner which >> doesn't require using the TargetOptions object in the optimizer? > > a flag on each floating point operation, saying whether it does > "exact" math or > not?Yes, the right approach for this is to add flags to each fp operations just like the NUW/NSW bits on integer ops. We want the ability to represent the C99 pragmas which are scoped more tightly than a function body. 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 don't have enough expertise to propose exactly how this should work. -Chris
> 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
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' bitSounds 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' bitDoes 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>