[PATCH] D104013: [LangRef] State that the based-on relation is for pointer typed values only

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune updated this revision to Diff 351764.
aqjune added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104013

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2655,40 +2655,54 @@
 undefined. Pointer values are associated with address ranges according
 to the following rules:
 
--  A pointer value is associated with the addresses associated with any
-   value it is *based* on.
--  An address of a global variable is associated with the address range
+-  A pointer to a global variable is associated with the address range
    of the variable's storage.
 -  The result value of an allocation instruction is associated with the
    address range of the allocated storage.
 -  A null pointer in the default address-space is associated with no
-   address.
--  An :ref:`undef value <undefvalues>` in *any* address-space is
-   associated with no address.
--  An integer constant other than zero or a pointer value returned from
-   a function not defined within LLVM may be associated with address
-   ranges allocated through mechanisms other than those provided by
+   address range.
+-  An :ref:`undef value <undefvalues>` and :ref:`poison value <poisonvalues>`
+   in *any* address-space is associated with no address range.
+-  A pointer cast from an integer constant other than zero, a pointer that is
+   cast from zero and its address space does not have a null pointer,
+   or a pointer value returned from a function not defined within LLVM
+   may be associated with
+   address ranges allocated through mechanisms other than those provided by
    LLVM. Such ranges shall not overlap with any ranges of addresses
    allocated by mechanisms provided by LLVM.
+-  Otherwise, a pointer value is associated with the addresses associated with
+   a pointer value it is *based* on, the definition of which is described
+   below.
 
 A pointer value is *based* on another pointer value according to the
 following rules:
 
 -  A pointer value formed from a scalar ``getelementptr`` operation is *based* on
    the pointer-typed operand of the ``getelementptr``.
--  The pointer in lane *l* of the result of a vector ``getelementptr`` operation
-   is *based* on the pointer in lane *l* of the vector-of-pointers-typed operand
-   of the ``getelementptr``.
+-  The pointer in lane ``l`` of the result of a vector ``getelementptr``
+   operation is *based* on the pointer in lane ``l`` of the
+   vector-of-pointers-typed operand of the ``getelementptr``.
 -  The result value of a ``bitcast`` is *based* on the operand of the
    ``bitcast``.
--  A pointer value formed by an ``inttoptr`` is *based* on all pointer
-   values that contribute (directly or indirectly) to the computation of
-   the pointer's value.
 -  The "*based* on" relationship is transitive.
 
 Note that this definition of *"based"* is intentionally similar to the
 definition of *"based"* in C99, though it is slightly weaker.
 
+Only pointer-typed values are associated with address ranges.
+Non-pointer values such as '``i64 %i``' or '``double %j``' are not associated
+with any address ranges.
+This is necessary to explain optimizations relying on arithmetic properties
+because they assume these types do not carry such information.
+Casting a pointer value to an integer via
+:ref:`ptrtoint operation <i_ptrtoint>` or reinterpreting the pointer value
+stored in the memory by loading it as a non-pointer type loses its associated
+address range.
+
+Given '``i = ptrtoint p; q = inttoptr i to ty*``', it is incorrect
+to assume that ``q`` is only based on ``p`` because the value of ``i`` could
+have been contributed by another pointer via conditional branches as well.
+
 LLVM IR does not associate types with memory. The result type of a
 ``load`` merely indicates the size and alignment of the memory from
 which to load, as well as the interpretation of the value. The first


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D104013.351764.patch
Type: text/x-patch
Size: 3854 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210614/1ba76873/attachment.bin>