[PATCH] D21723: [RFC] Enhance synchscope representation

[Tony Tye via llvm-commits]

tony-tye added a comment.

I would argue that even without (2) there is a case for using standard LLVM atomic instructions as it makes it possible to generate the same IR for a given language regardless of whether the target supports scopes. It seems CLANG is moving towards generating LLVM IR atomics directly rather than calls to built-ins so this approach would support that. Currently LLVM already supports two scopes. It also makes code generation much simpler as the existing machine instructions can be used and so avoid creating a large number of pseudo instructions. The patches https://reviews.llvm.org/D24577 and https://reviews.llvm.org/D24623 that are under review are pretty simple and do that. There would be a lot more code if intrinsics had to be used.

But I agree that a major motivation for this is so that optimizations can be written that will benefit all languages including those that have scopes. For example, currently it appears that atomic machine instructions have to be marked as volatile to ensure that the machine code instruction scheduler will insert the necessary dependencies. This is conservatively correct, but if the memory machine instructions had the memory ordering information available it would be possible to only add dependencies in the direction required in a target neutral way. This does not require knowledge of the memory scope.

Optimizations that merge a finite series of atomics to the same location would require some knowledge of the memory scopes when they do not all match. Such optimizations would not be legal for volatile, but are allowed for atomics. It seems considering this information as target specific is not unreasonable. This is how address spaces appear to be handled currently. If alias analysis was to use address space information, then it would seem it would need to query the target to determine if two address spaces may alias (for example, for OpenCL the generic address space may alias other address spaces, but other address spaces do not alias each other).

Currently the concept of memory scope already exists in LLVM as the SynchonizationScope enumeration, and is encoded in bit code as a 32 bit value. Continuing to use an enumeration does not affect backwards compatibility and is adequate for code generation. Are there existing atomics optimizations that need to be updated to honor memory scope? Currently there are no uses of SynchonizationScope in any optimizations, even though there are two scopes currently defined. Are there plans for future atomic optimizations?

If in writing future optimizations a better representation is devised then it could always be changed as a separate patch at that time.


https://reviews.llvm.org/D21723