On Wed, 2020-11-25 at 10:53 +0100, Richard Biener wrote: > 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
Thanks for the explanation, that's good to know. I'll need to rather ad just my test expectations then. Best regards, Ilya
