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

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune created this revision.
aqjune added reviewers: hfinkel, reames, nlopes, lattner, jdoerfert, nhaehnle.
Herald added a subscriber: arichardson.
aqjune requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This patch suggests a clarification of the definition of based-on relation.
This includes:

- Mentioning that the based-on relation is a relation between pointer-typed values only
- Non-pointer typed values do not have associated address ranges
- And a few updates, including a statement saying that `inttoptr(ptrtoint p)` isn't based on `p`

While trying to convey meaningful updates, I also tried to make changes small as well.
For example, the precise meaning of `inttoptr` isn't suggested in this patch.
Also, term 'provenance' is intentionally not introduced because the change isn't necessary yet.
There are very many topics that are not addressed (as mentioned in '[RFC] Introducing a byte type to LLVM'), and dealing with all of them would require too much effort.
They should be done after enough discussion about them is done.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104013

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2654,40 +2654,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 casted from 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
    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.
+   Given '``i = ptrtoint p; q = inttoptr i to ty*``', it is incorrect
+   to assume that ``q`` is based on ``p`` because the value of ``i`` could have
+   been contributed by another pointer via conditional branches as well.
 -  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.
+
 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.351092.patch
Type: text/x-patch
Size: 3764 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210610/1377d715/attachment.bin>