On Wed, Sep 3, 2014 at 12:28 PM, Olivier Hainque <hain...@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 <hain...@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;
> }
>
