This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Feb 23, 2012 at 10:11 PM, Aldy Hernandez <aldyh@redhat.com> wrote:
> On 02/23/12 12:19, Aldy Hernandez wrote:
>
>> about hit me. Instead now I save all loads in a function and iterate
>> through them in a brute force way. I'd like to rewrite this into a hash
>> of some sort, but before I go any further I'm interested to know if the
>> main idea is ok.
>
>
> For the record, it may be ideal to reuse some of the iterations we already
> do over the function's basic blocks, so we don't have to iterate yet again
> over the IL stream. ?Though it may complicate the pass unnecessarily.

It's definitely ugly that you need to do this.  And yes, you have to look at
very many passes I guess, PRE comes to my mind at least.

I still do not understand the situation very well, at least why for

 transaction { for () if (b) load; } load;

it should be safe to hoist load out of the transaction while for

 load; transaction { for () if (b) load; }

it is not.  Neither do I understand why it's not ok for

 transaction { for () if (b) load; }

to hoist the load out of the transaction.

I assume all the issue is about hoisting things over the trasaction start.
So - why does the transaction start not simply clobber all global memory?
That would avoid the hoisting.  I assume that  transforming the above to

 transaction { tem = load; for () if (b) = tem; }

is ok?

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]