Re: [patch] prevent tree sinking of trapping stmts

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

On Wed, Sep 3, 2014 at 12:28 PM, Olivier Hainque <hainque@adacore.com> wrote:
> Hello,
>
> For the testcase below, the tree-ssa-sink pass sinks the first a = b + c;
> assignment within the if branch.
>
> This is problematic when the + operation on floats could trap, as it gets moved
> out of the path that dominates the call in the else branch and a trap on the
> original + should prevent the call from taking place.
>
> The attached patch is a proposal to address this by refusing to sink statements
> that could trap, except load/stores. Trapping loads or stores typically yield
> undefined behavior anyway, and not sinking a load or store as soon as it is
> potentially trapping pessimizes quite a bit for no valid reason.

I don't quite follow this reasoning.  Why would a trapping FP operation
not be undefined behavior without -fnon-call-exceptions?  That is,
don't you want to check stmt_could_throw_p?

That is, what's the "real" testcase you are trying to fix?

Richard.

> Bootstrapped and regression tested on x86_64-linux-gnu.
>
> OK to commit ?
>
> Thanks in advance for your feedback,
>
> With Kind Regards,
>
> Olivier
>
>
> 2014-09-03  Olivier Hainque  <hainque@adacore.com>
>
>         * tree-ssa-sink.c (statement_sink_location): Don't sink !load-or-store
>         stmts that could trap.
>
>         testsuite/
>         * gcc.dg/tree-ssa/ssa-sink-13.c: New test.
>
>
> [see attached file: sinktrap.diff]
>
> --
>
> extern void bar ();
>
> float foo (int call)
> {
>   float a, b, c;
>
>   a = b + c;
>   if (!call)
>     ;
>   else
>     {
>       bar ();
>       b = c * 2;
>       a = b + c;
>     }
>
>   return a;
> }
>