On Tue, 2012-03-06 at 21:18 +0100, Richard Guenther wrote:
> On Tue, Mar 6, 2012 at 6:55 PM, Aldy Hernandez <al...@redhat.com> wrote:
> > On 02/29/12 03:22, Richard Guenther wrote:
> >
> >> So fixing up individual passes is easier - I can only think of PRE being
> >> problematic right now, I am not aware that any other pass moves loads
> >> or stores.  So I'd simply pre-compute the stmt bit in PRE and adjust
> >> the
> >>
> >>           if (gimple_has_volatile_ops (stmt)
> >>               || stmt_could_throw_p (stmt))
> >>             continue;
> >>
> >> in compute_avail accordingly.
> >
> >
> > Initially I thought PRE would be problematic for transactions, but perhaps
> > it isn't.  As I understand, for PRE we hoist loads/computations that are
> > mostly redundant, but will be performed on every path:
> >
> >        if (flag)
> >                a = b + c;
> >        else
> >                stuff;
> >        d = b + c;              <-- [b + c] always computed
> >
> > Even if we hoist [b + c] before the flag, [b + c] will be computed on every
> > path out of "if (flag)...".  So... we can allow this transformation within
> > transactions, right?

In this particular example, I agree.  We can move [b + c] into the else
branch, and then move it to before flag because it will happen on all
paths to the exit anyway.

> Note that partial PRE (enabled at -O3) can insert expressions into paths
> that did _not_ execute the expression.  For regular PRE you are right.

I suppose if only loads will be moved around by PRE, then this could be
fine, as long as those expressions do not have visible side effects or
can crash if reading garbage.  For examples, dereferencing pointers
could lead to accessing unmapped memory and thus segfaults, speculative
stores are not allowed (even if you undo them later on), etc.

Also, if PRE inserts expressions into paths that did not execute the
transactions, can it happen that then something like loop invariant
motion comes around and optimizes based on that and moves the code to
before "if (flag)..."?  If so, PRE would break publication safety
indirectly by pretending that the expression happened on every path to
the exit, tricking subsequent passes to believe things that were not in
place in the source code.  Is this a realistic scenario?

Reply via email to