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 >> >> 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?
I think so. Richard.
