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, 2012-04-12 at 08:21 -0400, Andrew MacLeod wrote:
> On 04/11/2012 06:38 PM, Torvald Riegel wrote:
> > On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> >>
> > 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.
> >
> >
> Does it make any sense to simply predefine the possible valid 
> combinations with the HLE bit already set?  it at least removes any 
> possible invalid combinations and forces the programmer to consciously 
> choose their memory model.
> ie,
> or whatever happens to be valid...   Doesn't really scale to adding more 
> new bits later, but perhaps that doesn't matter.

I would suggest that we keep the HLE acq/rel bits independent of the
memory order bits.  Both are independent on a conceptual level.  And we
should add documentation that tells programmers that memory orders need
always be specified.

This way, we:
- keep it generic and don't add any arch-specific assumptions,
- remain closer to a true extension of the C++11/C11 atomics instead of
  a more strongly coupled mix-up,
- can still do arch-specific selection of memory orders (e.g., even just
  the memory orders are more fine-granular than you'd need for just
- can still do arch-specific warnings if some combinations really don't
  make sense,
- keep the number of macros small as preferred by Jakub.

Would that be an acceptable option for everyone?  Andi, would proper
documentation resolve your ease-of-use concerns?

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