[llvm-dev] Precise meaning of must alias?

[Chris Lattner via llvm-dev]

> 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.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190219/48c3e4df/attachment.html>