[llvm-dev] Precise meaning of must alias? (original) (raw)

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 18 19:02:28 PST 2019

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>

More information about the llvm-dev mailing list