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?
