[llvm-dev] Precise meaning of must alias?

[Chandler Carruth via llvm-dev]

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> wrote:

> I can see four possible meanings of must alias:
>
>    1. 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.)
>    2. 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.)
>    3. 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.)
>    4. 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.

Perhaps this never comes up with MustAlias, but it absolutely comes up with
NoAlias where the pointers may in fact be equal bit patterns. I would find
it very confusing for them to be defined differently.

(And again, this obviously is not relevant to your example IR where they
are literally the same pointer as BasicAA resolves the query, precisely as
Chris said.)
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190218/edf205de/attachment.html>