> Let me rephrase: why is it preferable to add first class instruction support for opaque scope rather than using intrinsics?Given that LLVM core now supports atomic instructions, it would seem desirable to use them for all languages supported by LLVM. This would allow optimizations to be aware of the memory semantics. By using intrinsics this information no longer becomes available in a unified way. It also requires the target code generator to support both the LLVM atomics as well as all the additional intrinsics. In general it seems preferable to use a single approach rather than multiple approaches to express information. Currently LLVM has support for atomics by specifying both the memory ordering and memory scope as enumerated values specified by an enum type. However, the values for memory scope currently only include those needed for CPU-style targeted languages. Languages such as CUDA and OpenCL introduce additional memory scopes into the memory model. This patch extends the existing enumeration for memory scope to allow the target to define additional memory scopes that can be used by such languages. The current bit code already represents the memory scope as a 32 bit unsigned value, so this change introduces no backward compatible issues. Thanks, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/b0ea79ce/attachment.html>
> On Aug 23, 2016, at 2:00 PM, Tye, Tony <Tony.Tye at amd.com> wrote: > > > Let me rephrase: why is it preferable to add first class instruction support for opaque scope rather than using intrinsics? > > Given that LLVM core now supports atomic instructions, it would seem desirable to use them for all languages supported by LLVM.> This would allow optimizations to be aware of the memory semantics.Since the scope is “opaque” and target specific, can you elaborate what kind of generic optimization can be performed? — Mehdi> By using intrinsics this information no longer becomes available in a unified way. It also requires the target code generator to support both the LLVM atomics as well as all the additional intrinsics. In general it seems preferable to use a single approach rather than multiple approaches to express information. > > Currently LLVM has support for atomics by specifying both the memory ordering and memory scope as enumerated values specified by an enum type. However, the values for memory scope currently only include those needed for CPU-style targeted languages. Languages such as CUDA and OpenCL introduce additional memory scopes into the memory model. This patch extends the existing enumeration for memory scope to allow the target to define additional memory scopes that can be used by such languages. The current bit code already represents the memory scope as a 32 bit unsigned value, so this change introduces no backward compatible issues. > > Thanks, > -Tony-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/88188e70/attachment.html>
> Since the scope is “opaque” and target specific, can you elaborate what kind of generic optimization can be performed?Some optimizations that are related to a single thread could be done without needing to know the actual memory scope. For example, an atomic acquire can restrict reordering memory operations after it, but allow reordering of memory operations (except another atomic acquire) before it, regardless of the memory scope. Thanks, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/be78b51c/attachment-0001.html>