On Thu, Jan 4, 2018 at 10:27 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > (just a log of my thoughts while reading the patch) > > On Thu, 4 Jan 2018, Wilco Dijkstra wrote: > >> Richard Biener wrote: >>> >>> On Tue, Oct 17, 2017 at 6:28 PM, Wilco Dijkstra <wilco.dijks...@arm.com> >>> wrote: >> >> >>>> +(if (flag_unsafe_math_optimizations) >>>> + /* Simplify (C / x op 0.0) to x op 0.0 for C > 0. */ >>>> + (for op (lt le gt ge) >>>> + neg_op (gt ge lt le) >>>> + (simplify >>>> + (op (rdiv REAL_CST@0 @1) real_zerop@2) >>>> + (switch >>>> + (if (real_less (&dconst0, TREE_REAL_CST_PTR (@0))) >>> >>> >>> Note that real_less (0., +Inf) so I think you either need to check C is >>> 'normal' >>> or ! HONOR_INFINITIES. >> >> >> Yes, it was missing an explicit check for infinity, now added. > > > I don't understand how the check you added helps. > >>> There's also the underflow issue I guess this is what >>> -funsafe-math-optimizations >>> is for. I think ignoring underflows is dangerous though. >> >> >> We could change C / x > 0 to x >= 0 so the underflow case is included. >> However that still means x == 0.0 would behave differently - so the >> question is >> what exactly does -funsafe-math-optimization allow? > > > That is indeed unclear. HONOR_SIGNED_ZEROS, HONOR_NANS, HONOR_INFINITIES are > better defined and could also see some use. > > 1/X>=0: if X can be zero (and the inverse can be infinite), the result > depends on the sign of that zero. If !HONOR_SIGNED_ZEROS || > !HONOR_INFINITIES, it looks like we can simplify to either X>0 or X>=0, > doesn't matter which. > 1/X>=0 is true iff X is not NaN and the sign bit is not set, so with > !HONOR_NANS it could also be turned into a bit test. > > It works the same for C/X>=0 with 0<C<infinity. For C=infinity, the main > difference is that X=infinity now gives false (if HONOR_NANS). > > C/X>0 is more tricky because small/big may round to zero. For C large enough > (assuming denormals, 1 is large enough for instance), the only new issue is > X=infinity. For smaller C, we start getting wrong results for finite values > of X, and presumably that's where flag_unsafe_math_optimizations comes into > play. > > If we consider flag_unsafe_math_optimizations as a kitchen sink that implies > !HONOR_SIGNED_ZEROS && !HONOR_INFINITIES, then you don't even need your > REAL_VALUE_ISINF test.
Without looking at the latest patch -funsafe-math-optimizations is a kitchen-sink we should avoid at all cost. In the past we somewhat decided to break it up properly (-fassociative-math and friends have been added for example), and we really don't want to add more stuff under this umbrella (there's too much under it already). I'm not sure if C / x op 0.0 to x op 0.0 is association though (I'm quite sure it isn't), so citing association examples doesn't work for me here ;) It might be we need some new flag like -fassume-infinite-precision-math to cover the underflow issue? We do have -ffinite-math-only but that shouldn't allow GCC to possibly introduce +-Inf for overflow - GCC just can assume there are no overflows in the original user expression. Richard. > -- > Marc Glisse
