llvm dev - Aug 2016 - Memory scope proposal

> 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>