This is the mail archive of the
gcc-patches@gcc.gnu.org
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 <aldyh@redhat.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.
>>
>>
>> r~
>
>
> 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
the
if (gimple_has_volatile_ops (stmt)
|| stmt_could_throw_p (stmt))
continue;
in compute_avail accordingly.
Richard.
> Thanks.