This is the mail archive of the
mailing list for the GCC project.
Re: [PR51752] publication safety violations in loop invariant motion pass
On Tue, Feb 28, 2012 at 9:11 PM, Aldy Hernandez <email@example.com> wrote:
> On 02/28/12 13:12, Richard Henderson wrote:
>> On 02/28/12 09:44, Aldy Hernandez wrote:
>>> ? ? ? ?PR middle-end/51752
>>> ? ? ? ?* gimple.h (gimple_in_transaction): New.
>>> ? ? ? ?(gimple_set_in_transaction): New.
>>> ? ? ? ?(struct gimple_statement_base): Add in_transaction field.
>>> ? ? ? ?* tree-ssa-loop-im.c: (movement_possibility): Restrict movement of
>>> ? ? ? ?transaction loads.
>>> ? ? ? ?(tree_ssa_lim_initialize): Compute transaction bits.
>>> ? ? ? ?* tree.h (compute_transaction_bits): Protoize.
>>> ? ? ? ?* trans-mem.c (tm_region_init): Use the heap to store BB
>>> ? ? ? ?auxilliary data.
>>> ? ? ? ?(compute_transaction_bits): New.
>> Looks good. ?Thanks for your patience.
> Thank you. ?I have committed the patch.
> I will also look into the tree_could_trap business (and PRE and other
> passes) to see if we can divine some context. ?But I probably won't get to
> it before early next week.
The tree_could_trap business is definitely harder because you lack
a stmt context - this helper takes a 'tree' argument. And it's not enough
to adjust gimple_could_trap as both are used regularly...
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.