[llvm-dev] Precise meaning of must alias?
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 19 14:23:39 PST 2019
> On Feb 18, 2019, at 7:02 PM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> A slight clarification to this and Chris's response just so that it doesn't cause confusion in the future (it isn't relevant to your example):
> On Mon, Feb 11, 2019 at 1:15 PM Philip Reames via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I can see four possible meanings of must alias:
> A must alias result indicates that the exact same bits in memory are accessed by both. (This requires both pointer and size to be equal at runtime.)
> A must alias result indicates that *at least one* bit in memory is accessed by both. (This allows unequal pointers, and unequal sizes, but not zero sizes.)
> A must alias result indicates that the two pointers must be equal when accessed at runtime. (This allows unequal sizes, and zero sizes, but restricts the pointers to be equal.)
> A must alias result indicates that *at least one* bit in memory is accessed by both, unless one of the two accesses has size 0 at runtime. (This is the weakest.)
> I'd always thought that (1) was the correct answer, but now I find myself wondering. From the code, (3) seems to be the closest match to what we actually implement, but we're not entirely consistent there either. What do others think?
> I agree that the intent is #3, but there is a gotcha IMO: the pointers need not be the *same*, but merely equivalent for the purpose of loading and storing to memory.
> I don't believe that it would be correct to CSE the pointer values as I understand the definition of aliasing. Aliasing is a property of the underlying *memory* and not fundamentally of the pointer itself.
Absolutely right. A “must alias” result isn’t enough to RAUW one pointer with another. They could have different LLVM types, they might not dominate each other, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev