[PATCH] D88860: [LangRef] Describe why the pointer aliasing rules are currently unsound.

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune added inline comments.


================
Comment at: llvm/docs/LangRef.rst:2558
+The inttoptr hole
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The pointer aliasing rules currently don't have a consistent interpretation in
----------------
The contents below talk about loads that produce pointers as well - maybe the title should be more comprehensive?


================
Comment at: llvm/docs/LangRef.rst:2571
+pointer, followed by a load of the same pointer, it can't be simplified to
+the operand of the store.
+
----------------
Let's talk about inttoptr in this paragraph first, and talk about load pointers as separate paragraph(s). I believe inttoptr already has quite a few things to talk about.

I think it is important to mention that, with this inttoptr semantics, inttoptr isn't a scalar operation anymore. It cannot be freely hoisted or sunk across pointer escaping instructions, but it is currently done by LLVM.
Considering that a function with inttoptr is currently tagged as `readnone`, this will bring a non trivial change in performance, so it will be desirable to keep inttoptr as scalar ops. I suggest making this explicit in the text.

Another possible semantics that would be good to mention here too is to make `inttoptr i` simply based on `i`.
The caveat of the semantics is that requires defining based-on relation between non-pointer values as well, which is super tricky; for example, given two integers i and j, `if (i == j) use(i)` cannot be optimized to `if (i == j) use(j)` anymore because i and j may be based on different objects. Also, there are big amount of int/float operations (shift, icmp, fptosi, ...) to deal with.


================
Comment at: llvm/docs/LangRef.rst:2578
+escaped pointer. This description leaves a lot of open questions regarding the
+interaction between pointer operations and non-pointer operations.
+
----------------
FYI: Alive2 uses this semantics, and it returns poison when a pointer-byte is read as a non-pointer type (and vice versa). The main blocker is a load type canonicalization in InstCombine, which changes load pointer to load i64.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88860/new/

https://reviews.llvm.org/D88860