Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen <andi at firstfloor dot org>]

On Thu, Apr 12, 2012 at 12:38:44AM +0200, Torvald Riegel wrote:
> On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> > > Tests passing, bootstrap in progress.
> > > 
> > > Comments?
> > 
> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> > see that in the code. I think that's really required, otherwise the optimizer
> > will do the wrong thing and move memory references outside the region.
> 
> Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START /
> HLE_END instead?  Not particularly great names, but at least it avoids
> overloading ACQUIRE/RELEASE and thus should make it clearer that you
> still need to specify a memory order.

It still seems wrong to me. HLE is an x86 construct, so weaker
memory orders on the compiler level than what the instruction implements
does not really make sense to me. And the instruction just has LOCK
semantics.

Currently it's highly error prone -- on the Russel hard to misuse scale not higher 
than 1 as is [1]

At the minimum it would need a warning with RELAXED as suggested
by Jakub earlier.


> I agree with Jakub that users really should specify memory order bits,
> if they want ordering.  Andi, I also see your point regarding catching
> bugs, but this is really expert stuff, and my hope is that we can make
> HLE really transparent or at least provide better abstractions around it

At least this form of HLE cannot be transparent, it has to be annotated by the
programmer.

-Andi

[1] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
-- 
ak@linux.intel.com -- Speaking for myself only.