On 03/07/12 03:18, Richard Guenther wrote:
On Tue, Mar 6, 2012 at 9:56 PM, Torvald Riegel<trie...@redhat.com> wrote:
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
if (gimple_has_volatile_ops (stmt)
|| stmt_could_throw_p (stmt))
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:
a = b + c;
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
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?
I think so.
Wow, yeah. I hadn't thought about that.
Fortunately in the current code base this won't happen because loop
invariant motion will refuse to move _any_ loads that happen inside a
transaction, and because of the memory barrier at the beginning of
transactions, no code will be moved out of a transaction. However, when
we optimize things (4.8?) and allow loop invariant motion inside
transactions when the load happens on every path to exit, then yes... we
need to keep this problematic scenario in mind.
For now I believe we're safe, modulo the partial PRE scenario that
Richard G pointed out.