[RFC] Add Intel TSX HLE Support

Hi All,

I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to
specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order
flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to
change LLVM/clang by adding:

+ a metadata 'targetflags' in LLVM atomic IR to pass this
  target-specific memory model hint

+ one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints
  This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode

  here is the current SDNode class hierarchy of memory related nodes

  SDNode -> MemSDNode -> LSBaseNode -> LoadSDNode
                    > + -> StoreSDNode
                    + -> AtomicSDNode
                    + -> MemIntrinsicSDNode

  here is the current SubclassData definitions:

  bit 0~1 : extension type used in LoadSDNode
  bit 0 : truncating store in StoreSDNode
  bit 2~4 : addressing mode in LSBaseNode
  bit 5 : volatile bit in MemSDNode
  bit 6 : non-temporal bit in MemSDNode
  bit 7 : invariant bit in MemSDNode
  bit 8~11: memory order in AtomicSDNode
  bit 12 : synch scope in AtomicSDNode

  Considering the class hierarchy, we could safely reused bit 0~1 as the target flags in AtomicSDNode/MemIntrinsicNode
+ X86 backend is modified to generate additional XACQUIRE/XRELEASE prefix based on the specified target flag

The following are details of each patch:

* 0001-Add-targetflags-in-AtomicSDNode-MemIntrinsicSDNode.patch

This patch adds 'targetflags' support in AtomicSDNode and MemIntrinsicSDNode. It will check metadata 'targetflags' and embedded its value into SubclassData. Currently, only two bits are defined.

* 0002-Add-HLE-target-feature.patch

This patch adds HLE feature and auto-detection support

* 0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch

This patch adds XACQUIRE/XRELEASE prefix and its assembler/encoding support

* 0004-Enable-HLE-code-generation.patch

This patch enables HLE code generation by extending the current logic to handle 'targetflags'.

* 0001-Add-target-flags-support-for-atomic-ops.patch

This patch adds target flags support in __atomic_* builtins. It splits the whole 32-bit order word into high and low 16-bit parts. The low 16-bit is the original memory order and the high 16-bit will be re-defined as target-specific flags and passed through 'targetflags' metadata.

* 0002-Add-mhle-option-support-and-populate-pre-defined-mac.patch

It adds '-m[no]hle' option to turn on HLE feature or not. Once HLE feature is turned on, two more macros (__ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE) are defined for developers to mark atomic builtins.

Thanks for your time to review!

- Michael

0001-Add-targetflags-in-AtomicSDNode-MemIntrinsicSDNode.patch (31.2 KB)

0002-Add-HLE-target-feature.patch (3.77 KB)

0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch (8.57 KB)

0004-Enable-HLE-code-generation.patch (56.8 KB)

0001-Add-target-flags-support-for-atomic-ops.patch (17.3 KB)

0002-Add-mhle-option-support-and-populate-pre-defined-mac.patch (6.39 KB)

Hi Michael,

Why do you want to add transactional memory support to LLVM ? Can't you implement transactional memory using a library call ? Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM.


Nadav, I've been reading over the patches and I was wondering if you could elaborate your concerns here. I share your goal of reducing compilation time regressions for users that don't care about new feature X. From my very quick glance over the patches, I didn't see anything I couldn't opt out of. Maybe we can talk about specifics and figure out a way to make these changes not affect other users/targets.

Let's say I care about a non-X86, non-TM target and compilation time. What's the negative impact to me from these patches? Is there a cost I can't opt out of?

Let's say I care about X86 non-TM compilation time, what additional costs am I burdened with?

Hi Michael (Ilseman),

As a non-x86 user you are going to have a slight negative impact on compile time and compiler code size. Its not a big deal. You need to pass additional parameters to all of the visitAtomicXXX && LegalizeXX methods. The initialization of Atomic operations will be slower because of the extra checks. Also, out of tree targets need to be updated. I don’t think that this is a big deal, it is just another small increase in the compiler size and compile time.