[PATCH] Document HLE metadata

Jeffrey Yasskin jyasskin at googlers.com
Wed Feb 27 15:17:59 PST 2013


On Wed, Feb 27, 2013 at 2:54 PM, Michael Liao <michael.hliao at gmail.com> wrote:
> On Wed, 2013-02-27 at 14:22 -0800, Jeffrey Yasskin wrote:
> The execution here only refer to the atomic ops on the atomic variable.
> The description here is to address two possible states after this atomic
> ins, i.e. either in transactional state or not.

If you want to create two states for an execution to be in, you'd have
to describe how other instructions cause transitions between the
states, which I don't see in your current patch, and which seems
harder than describing the hint this metadata provides to targets.
Feel free to try though.

>> For example, one plausible explanation might be:
>>
>> >>>>>>>>>>>>>
>> The '!hle.lock !"acquire"' metadata on an atomic instruction that modifies a variable hints that
>> 1) The variable is likely to be shared with other threads.
>> 2) The next atomic instruction annotated with '!hle.lock' is likely to be annotated with '!hle.lock !"release"', operate on the same address and type, and set it back to its original value.
>> 3) Intervening instructions are likely to be only memory operations with no non-memory side effects.
>
> I assume people have the basic knowledge of implementing lock upon
> atomic builtins, like paring acquire and release on the same atomic
> variable and setting back its original state when unlocking. Putting
> them here definitely won't hurt but may be verbose.

When reading this section, people don't necessarily know what
"Hardware Lock Elision", an "elided lock", or an "HLEd critical
section" is. We also don't know whether these primitives are useful
for recursive mutexes or shared mutexes. The description here needs to
tell us, either by defining the hints in terms of the existing atomic
primitives and memory model or by defining the precise lock
abstraction it's talking about.

> I don't understand the point 3. Could you put more details on that?

Presumably the transaction gets aborted on a syscall or an operation
on a memory-mapped IO address?

>> If the hints are violated, the program must still execute as if the !hle.lock metadata were not present.
>
> Sure, I will add sentence to on this. All hint should not break
> correctness if not properly used.

That's not quite true. I believe the !range metadata
(http://llvm.org/docs/LangRef.html#range-metadata) implies undefined
behavior if the value loaded is outside the promised range. So I think
this statement, that !hle.lock does *not* cause undefined behavior, is
needed.

>> Certain targets (e.g. <a href="http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions">Intel x86 processors post-Haswell</a>) can take advantage of this hint by speculatively skipping the write, recording memory operations until the matching release, and applying the batch atomically if the hints were accurate and no other thread conflicted with the operations, or restarting the whole sequence at the acquire-annotated instruction if a hint was violated or another thread modified an address accessed by this sequence.
>
> We could refer other TM supported hardware here if people want to ensure
> it should not be a target specific feature.

We could, but I don't think that's necessary if the definition is in
terms of the rest of the LLVM IR.

Thanks,
Jeffrey

http://llvm-reviews.chandlerc.com/D475




More information about the llvm-commits mailing list