[LLVMdev] Loads moving across barriers

Andrew Trick
2013-12-05T00:29:22Z

On Dec 4, 2013, at 3:33 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> On 11/11/2013 03:13 PM, Andrew Trick wrote:
>> On Nov 9, 2013, at 1:39 PM, Matt Arsenault <arsenm2 at gmail.com>
wrote:
>>
>>> On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at
google.com> wrote:
>>>
>>>> Perhaps you're instead trying to say that with certain
address spaces "noalias" (and by inference, "restrict" at
the language level) has a different semantic model than other address spaces?
While it's less worrisome than the first interpretation, I still don't
really like it.
>>>>
>>> This sounds right. With the constant address space, anything you do
is OK since it’s constant. Private address space is supposed to be totally
inaccessible from other workitems, so parallel modifications aren’t a concern.
The others require explicit synchronization which noalias would need to be aware
of.
>> FWIW, it seems generally useful to me to have a nomemfence function
attribute and intrinsic property. We should avoid memory optimization (and
possibly other optimization) across these regardless of alias analysis.
>>
> I'm think I'll try implementing this. Ideally it would be
parameterized over the address space, so it makes more sense for it to be a
memfence attribute rather than a nomemfence. You would then have an arbitrary
number of memfence(N) attributes for each required address space.

So for correctness, would we need to tag all functions with memfence(0..M) until
we can prove otherwise? That seem heinous. Better to have an optional attribute
that can be added to expose optimization. Is it important in practice to
optimize the case of memfence(I) + nomemfence(J)? If so, is there a problem with
nomemfence(N)?

-Andy