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. 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. 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. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
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.
On Mon, Dec 3, 2012 at 10:15 AM, Daniel Berlin <dberlin at dberlin.org> wrote:> On Mon, Dec 3, 2012 at 6:29 AM, Krzysztof Parzyszek >> 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.LLVM IR already has faced this problem, with the noalias argument attribute. My solution for this was to define NoAlias to ignore load-load dependencies, on the theory that clients which would care about load-load dependencies should know that they care, so they could use a different API or pass a special flag into the AliasAnalysis API. The current definition has a few vague aspects, but as far as I know the basic concept works. Dan