This is the mail archive of the 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 Fri, 2012-02-24 at 10:34 -0600, Aldy Hernandez wrote:
> On 02/24/12 07:10, Torvald Riegel wrote:
> > safety.  I didn't have time to look at Aldy's patch yet, but a first
> > safe and conservative way would be to treat transactions as full
> > transformation barriers, and prevent publication-safety-violating
> > transformations _within_ transactions.  Which I would prefer until we're
> > confident that we understood all of it.
> Do you mean disallow hoisting of *any* loads that happen inside of a 
> transaction (regardless of whether a subsequent load happens on every 
> path out of the loop)?  This would definitely be safe and quite easily 
> doable, simply by checking if loads to be hoisted are within a transaction.

If we cannot get the less conservative approach in on time (the one
you've been working on), then we could also use this big hammer.  I
don't quite know how high performance degradation would be (we could
measure number of loads/stores at runtime with STAMP, for example, and I
could build the libitm code for that if you want), but having
publication-safety work correctly in 4.7 might be more important.

> >
> > For hoisting out of or across transactions, we have to reason about more
> > than just publication safety.
> Again, __transactions being barriers and all, I don't think we should 
> complicate things unnecessarily at this point, since it doesn't happen.

Yes.  Based on Richard Guenther's examples, my question was whether your
code (without having actually looked at it ;) ) would also allow
post-dominating loads in nontransactional code to enable hoisting (as in
the __transaction_atomic { if (foo) load; } load case.  I believe only
loads within the same transaction should count, and I wasn't sure
whether you were ensuring that (and/or whether a barrier would enforce
this either).


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