Re: [patch] prevent tree sinking of trapping stmts

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Sep 4, 2014 at 11:04 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Well, but that's a bug in the Ada frontend if it does exceptions behind
>> GCCs back.  ISTR that the middle-end also supports a SJLJ EH scheme?
>
> No and yes respectively.  As already explained multiple times, GNAT uses an
> SJLJ scheme which is entirely managed by the front-end and (manually) lowered
> into __builtin_setjmp/__builtin_longjmp and transparent to the middle-end,
> i.e. it doesn't use the middle-end EH support at all.  That's by design, as it
> frees us from linking with libgcc_eh.  I don't think that we want to change
> that and I'm wary of trying to let middle-end EH stuff creep in there.
>
> We could indeed use the middle-end SJLJ EH scheme (and we experimented with it
> in the past) but it's an entirely separate debate.

But then the proposed patch pessimizes code too much IMHO.
Moving traps later (or even removing them by removing dead code)
is fine.

OTOH this case is similar to how we prevent PRE from hoisting
a trapping expression across a call that may return abnormally
(like by calling exit(0)).  But not trapping has been seen as generally
ok (otherwise we could never DCE an integer division with non-constant
divisor, or never DCE FP math unless you specify -fno-trapping-math,
or never DCE a pointer-load because you could have arranged to
make it trap).

So I tend to think that removing / delaying traps is ok unless you
can catch them within the active EH scheme.

Certainly that Oliver excludes loads/stores (but not integer
division!) points at the fact that preserving the order of
traps with respect to other sequence points is no good
for optimization.

Consider

extern void bar ();
volatile int x;
float foo (int call)
{
  float a, b, c;

  a = b + c;
  if (!call)
    ;
  else
    {
      x = 1; // a "strong"(?) sequence point
      b = c * 2;
      a = b + c;
    }

  return a;
}

is a trap handler allowed to assume that the x = 1 store didn't
happen yet?  The C abstract machine strictly orders program
execution after sequence points (but it doesn't have a concept
of traps that not terminate the program).

In fact not sinking in the above case (no matter what side-effect
happens in the path sunken to) will likely pessimize code
considerably.

Richard.

> --
> Eric Botcazou