Reassociation and trapping operations

Reassociation and trapping operations

[Ilya Leoshkevich]

Hi!

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.  The following helps:

--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -2144,7 +2144,7 @@ eliminate_redundant_comparison (enum tree_code
opcode,
   if (TREE_CODE (curr->op) != SSA_NAME)
     return false;
   def1 = SSA_NAME_DEF_STMT (curr->op);
-  if (!is_gimple_assign (def1))
+  if (!is_gimple_assign (def1) || gimple_could_trap_p (def1))
     return false;
   lcode = gimple_assign_rhs_code (def1);
   if (TREE_CODE_CLASS (lcode) != tcc_comparison)
@@ -2160,7 +2160,7 @@ eliminate_redundant_comparison (enum tree_code
opcode,
       if (TREE_CODE (oe->op) != SSA_NAME)
        continue;
       def2 = SSA_NAME_DEF_STMT (oe->op);
-      if (!is_gimple_assign (def2))
+      if (!is_gimple_assign (def2) || gimple_could_trap_p (def2))
        continue;
       rcode = gimple_assign_rhs_code (def2);
       if (TREE_CODE_CLASS (rcode) != tcc_comparison)

However, I couldn't help noticing that other parts of reassociation
pass use stmt_could_throw_p, and trapping is mentioned only in one
place.  Is this intentional?  Shouldn't both throwing and trapping
block reassociation?

Best regards,
Ilya

Re: Reassociation and trapping operations

[Marc Glisse]

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.

-- 
Marc Glisse

Re: Reassociation and trapping operations

[Richard Biener]

On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse <marc.glisse@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

Re: Reassociation and trapping operations

[Ilya Leoshkevich]

On Wed, 2020-11-25 at 10:53 +0100, Richard Biener wrote:
> On Wed, Nov 25, 2020 at 8:15 AM Marc Glisse <marc.glisse@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

Re: Reassociation and trapping operations

[Joseph Myers]

On Wed, 25 Nov 2020, Richard Biener via Gcc wrote:

> > 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

-ftrapping-math is primarily about raising exception flags (the only form 
of floating-point exception handling supported in ISO C), not traps in the 
sense of change of control flow.  But it's true that GCC tends to do more 
moving flag raising (by virtue of not modelling the side effects) than 
eliminating it, and more eliminating it (at least in the case of 
apparently dead code, again since the side effects are not modelled) than 
introducing extra flag raising that doesn't occur in the abstract machine.

-- 
Joseph S. Myers
joseph@codesourcery.com