[llvm-dev] Out-of-line atomics implementation ways

Pavel Iliin via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 15 09:52:55 PDT 2020


Greetings everyone,
I am working on Aarch64 LSE out-of-line atomics support in LLVM, porting this GCC series: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01034.html
After local design experiments I've got some questions about upstream-suitable ways of implementation. More specifically:

1. Pass to expand atomics to library helper functions calls. 
These helpers test for the presence of LSE instructions and dispatch to corresponding sequence of instructions.
There are 100 helpers resulting from various combinations of instruction = { cas| swp | ldadd | ldset| ldclr| ldeor }, memory model = { relax, acq, rel, acq_rel } and size = {1, 2, 4 , 8, 16}.
I am considering two possibilities:
i.  Atomic Expand pass: add new AtomicExpansionKind::OutOfLine, and if it was set by target expand atomics to RTLIB libcalls. It will require to add 100 new "standardized" library names to   RuntimeLibcalls.def and redefine them for Aarch64 target to comply with libgcc implementation ( like this : "cas4_relax" -> " __aarch64_cas4_relax" )
ii. Lower atomics in question later on Instruction Selection pass: for Aarch64 out-of-line atomics targets replace atomicrmw/cmpxchg  to __aarch64 helpers libcalls. Then there is no need for runtime library calls extension, however this approach potentially gives less opportunity for compiler optimizations and appears to be more aarch64 specific.

2. Way of generating helpers code
To generate mentioned helpers and calls, preprocessor macros were used on gcc side and 'foreach' make targets on libgcc part of interface.
Concerning LLVM, compiler-rt library builtins readme states: "Each function is contained in its own file.  Each function has a corresponding unit test under test/Unit." and compilation is controlled by cmake. In addition, RuntimeLibcalls.def contains HANDLE_LIBCALL macros and would need to be redesigned to include compile time names generation.
So I have a choice of: 
i.  Slightly change/review some LLVM concepts and generate helpers on the fly. 
ii. Prepare all code locally and commit 100+ lines of names and files.

I would greatly appreciate any thoughts, suggestions and comments to create easy-to-go upstream patch,
Thanks in advance,
Pavel
 






More information about the llvm-dev mailing list