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: [i386, patch, RFC] HLE support in GCC

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

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


-- -- Speaking for myself only.

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