TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Patch by Javed Absar and Momchil Velikov
Details
- Reviewers
ostannard t.p.northover jdoerfert chill - Commits
- rGa36d31478c18: [AArch64] Add support for Transactional Memory Extension (TME)
rC367428: [AArch64] Add support for Transactional Memory Extension (TME)
rL367428: [AArch64] Add support for Transactional Memory Extension (TME)
rG4b8da3a503e4: [AArch64] Add support for Transactional Memory Extension (TME)
rL366322: [AArch64] Add support for Transactional Memory Extension (TME)
rC366322: [AArch64] Add support for Transactional Memory Extension (TME)
Diff Detail
Event Timeline
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
7223 ↗ | (On Diff #208668) | This error checking should be done in Sema::CheckBuiltinFunctionCall, not CodeGen. |
clang/test/CodeGen/aarch64-tme-errors.c | ||
1 ↗ | (On Diff #208668) | Tests for error messages should use clang's -verify option, and be in clang/test/Sema. |
llvm/include/llvm/IR/IntrinsicsAArch64.td | ||
745 | Why is this IR intrinsic marked as Throws, but the C intrinsic is nothrows (n)? | |
747 | Are you sure it's safe for this to be IntrNoMem and not IntrHasSideEffects? I think this means that all calls to this intrinsic can be folded together, even across transaction boundaries. More generally, I wonder if it would be safer to model all of these intrinsics as reading and writing memory, because we don't want them to be re-ordered with respect to any other memory accesses (though maybe IntrHasSideEffects is enough for that). Do we have any documentation on how these intrinsics change (if at all) the C or LLVM rules regarding data races? | |
llvm/lib/Target/AArch64/AArch64InstrFormats.td | ||
1028 | This isn't how we use instruction format classes. There should be one class here for each group with the same operands and encoding. Some of these might be able to re-use existing format classes if they fit into existing parts of the encoding space. | |
llvm/test/CodeGen/AArch64/tme.ll | ||
30 | It would be better to test each intrinsic in a separate function, so that this won't be affected by irrelevant codegen changes (e.g. basic block layout). | |
80 | Most of the attributes and metadata can be removed to simplify the test. |
llvm/include/llvm/IR/IntrinsicsAArch64.td | ||
---|---|---|
745 | I've now marked both as nothrow. | |
747 | It's indeed probably unsafe. I've changed ttest now to have side effects, so it's on the chain with tstart/tcommit/tcancel. I would like to impose the minimun set of restrictions regarding this set of intrinsics and associated instructions. There isn't yet a specification how this extension fits in the AArch64 or C/C++ memory model. Intuitively, regarding reordering of memory accesses, I would expect tstart to have Acquire semantics and tcommit - Release; but then that's speculation at this point, moreover I couldn't find a way to express that. So, now
|
@chill This is failing on buildbots with EXPENSIVE_CHECKS enabled: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/18684/steps/test-check-all/logs/stdio
llvm/test/CodeGen/AArch64/tme-tcancel.ll | ||
---|---|---|
1 ↗ | (On Diff #210768) | Would it make sense to add -verify-machineinstrs to all these Codegen/AArch64/tme-*.ll tests? |
If there are no objections, I'll go ahead with committing that Soon(tm) on the basis of previous acceptance.
I don't think the Sema checks need to be split over so many files. One for the whole of transactional seems enough. Similarly for CodeGen really.