[PATCH] D104013: [LangRef] State that the based-on relation is for pointer typed values only
Juneyoung Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 10 02:03:42 PDT 2021
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>
More information about the llvm-commits
mailing list