On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse <marc.gli...@inria.fr> wrote: > > On Wed, 25 Nov 2020, Ilya Leoshkevich via Gcc wrote: > > > I have a C floating point comparison (a <= b && a >= b), which > > test_for_singularity turns into (a <= b && a == b) and vectorizer turns > > into ((a <= b) & (a == b)). So far so good. > > > > eliminate_redundant_comparison, however, turns it into just (a == b). > > I don't think this is correct, because (a <= b) traps and (a == b) > > doesn't. > > > Hello, > > let me just mention the old > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53806 > > There has been some debate about the exact meaning of -ftrapping-math, but > don't let that stop you.
My interpretation has been that GCC considers traps not observable unless you compile with -fnon-call-exceptions which means that GCC happily elides them. That's usually in-line of user expectations with respect to optimization - they do not expect us to do less optimization just for the sake if there's a trap. Of course we do have to be careful to not introduce traps where there were none. In particular for say a <= b; foo (); you cannot rely on foo () never being called when a <= b traps because its effect on control flow is not modeled in the IL (we also happily DCE any such possibly trapping operation - the traps are not considered unmodeled side-effects). Even with -fnon-call-exceptions when the possible exception is not caught within the function there are probably similar issues with respect to code motion. Richard. > -- > Marc Glisse
