[llvm-dev] RFC: Element-atomic memory intrinsics

[Daniel Neilson via llvm-dev]

Hi Sanjoy,

> On May 8, 2017, at 3:55 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
> Hi Daniel,
> 
> On Mon, May 8, 2017 at 12:08 PM, Daniel Neilson <dneilson at azul.com> wrote:
>>>>      * isunordered param: bit 0 == 1 => stores to dest must be marked
>>>> ‘unordered’; bit 1 == 1 => loads from src must be marked ‘unordered'
>>> 
>>> What if the bits are zero -- will the stores / loads (depending on
>>> which bit) be "ordered" in that case, or something stronger?
>>> 
>> 
>> This is partly why I prefer option 2. An ‘isunordered’ value of 0 is nonsense for the standalone atomic-unordered memory intrinsic. It would imply that neither the source nor dest needs to be loaded/stored via unordered-atomic ops, and so the memory intrinsic is identical to the ordinary non-atomic one.
> 
> Perhaps the appropriate thing to do for this option is to not have the
> isunordered flag at all and instead call the intrinsic
> @llvm.memcpy_element_unordered_atomic?  I suspect we probably won't
> care about anything stronger than unordered atomic memcpys, and we can
> always generalize if there is a need later.

Removing that ‘isunordered’ parameter would mean that @llvm.memcpy_element_unordered_atomic() would require that both the src & dest arrays’ elements are accessed via unordered-atomic ops.  Leaving the parameter in we allow the possibility that only one of src/dest’s elements need to be accessed via unordered-atomic ops, and the other may be accessed via non-atomic ops. That added degree of freedom might be useful.

-Daniel