Re: [PR51752] publication safety violations in loop invariant motion pass

[Richard Guenther <richard.guenther@gmail.com>]

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.