On Thu, Apr 12, 2012 at 08:21:47AM -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,
> __ATOMIC_HLE_XACQ_CONSUME
> __ATOMIC_HLE_XACQ_ACQUIRE
> __ATOMIC_HLE_XACQ_ACQ_REL
> __ATOMIC_HLE_XACQ_SEQ_CST
>
> __ATOMIC_HLE_XREL_RELEASE
> __ATOMIC_HLE_XREL_ACQ_REL
> __ATOMIC_HLE_XREL_SEQ_CST
>
> or whatever happens to be valid... Doesn't really scale to adding
> more new bits later, but perhaps that doesn't matter.
I'd prefer not to predefine these. They can be surely defined in some intrinsic
header, but the number of predefined macros is already huge and is quite
costly (it appears in all -g3 macro info, increases compiler initialization
time even for empty sources, etc.).
Jakub
