[RFC] Add Intel TSX HLE Support

Eli Bendersky eliben at google.com
Tue Feb 19 14:24:29 PST 2013


Michael, while I'm not really following this thread in terms of
content, just a friendly advice - this patch jumble is completely
unmanageable. Consider using LLVM's Phabricator instance to simply
upload the patches to the code review tool and update them. This
should turn out to be much easier both for you and for reviewers.

Kind regards,
Eli



On Tue, Feb 19, 2013 at 2:14 PM, Michael Liao <michael.liao at intel.com> wrote:
> here is the patch! - michael
>
> On Tue, 2013-02-19 at 14:12 -0800, Michael Liao wrote:
>> Here is the patch 0004-Enable-HLE-code-generation.patch
>>
>> Yours
>> - Michael
>>
>> On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote:
>> > 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!
>> >
>> > Yours
>> > - Michael
>> > ---
>> > [1] http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01073.html
>> > [2] http://software.intel.com/sites/default/files/319433-014.pdf
>> >
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



More information about the llvm-commits mailing list