[LLVMdev] [RFC] Scoped no-alias metadata
Daniel Berlin
dberlin at dberlin.org
Mon Dec 3 10:15:35 PST 2012
On Mon, Dec 3, 2012 at 6:29 AM, Krzysztof Parzyszek
<kparzysz at codeaurora.org> wrote:
> On 12/2/2012 11:21 PM, Daniel Berlin wrote:
>>
>>
>> "During each execution of B, let L be any lvalue that has &L based on
>> P. If L is used to
>> access the value of the object X that it designates, and X is also
>> modified (by any means),then the following requirements apply:
>> ...
>> If these requirements are not met, then the behavior is undefined
>> "
>> (Note the last clause, requiring a modification for the requirements to
>> apply).
>>
>> So you can come up with arbitrarily complex aliased restrict pointers
>> and scopes, all of which share values,and as long as you don't modify
>> any of the objects, it's all okay.
>> Worse, none of the scoping requirements around restrict lifetimes
>> apply *unless* you modify the objects, since those are inside the
>> "..." part above.
>
>
> If the object isn't modified, then none of this matters. Nobody cares about
> aliasing between loads.
It's funny.
This was essentially my argument on the GCC list about 4 years ago (or
maybe it's longer now. i'm getting old), and someone brought up some
good examples where they cared about load-load aliasing, even besides
loop dependences analysis.
Let me see if i can hunt them down in the mailing list archives.
> What all this means is that is P is a restrict
> pointer that points to X, then no stores can modify X, unless they use
> addresses based on P. In other words, loads/stores to locations based on P
> can be aliased with each other, but not with any other loads or stores.
Yes.
> This implies that we need grouping of loads and stores to properly isolate
> those based on P from all the others. Attaching information to loads and
> stores individually may not be sufficient.
Yes.
More information about the llvm-dev
mailing list