[PATCH] D104547: [langref] attempt to clarify semantics of inttoptr/ptrtoint for non-integral types

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: efriedma, lebedev.ri, apilipenko, mkazantsev.
Herald added subscribers: jdoerfert, jfb, bollu, arichardson, mcrosier.
reames requested review of this revision.
Herald added a project: LLVM.

In review discussion on D104322 <https://reviews.llvm.org/D104322>, Eli and Roman quite reasonable raised concerns about the LangRef not really providing a precise definition for inttoptr/ptrtoint on non-integral types.  These had previously been disallowed, but I'd pragmatically allowed them in ac81cb7e6 <https://reviews.llvm.org/rGac81cb7e6dde9b0890ee1780eae94ab96743569b>.  This is my attempt to improve the situation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104547

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -601,11 +601,29 @@
 representation; that is, the integral representation may be target dependent or
 unstable (not backed by a fixed integer).
 
-``inttoptr`` and ``ptrtoint`` instructions converting integers to non-integral
-pointer types or vice versa are implementation defined, and subject to likely
-future revision in semantics. Vector versions of said instructions are as well.
-Users of non-integral-pointer types are advised not to design around current
-semantics as they may very well change in the nearish future.
+``inttoptr`` and ``ptrtoint`` instructions have the same semantics as for
+integral (i.e. normal) pointers in that they convert integers to and from
+corresponding pointer types, but there are additional implications to be
+aware of.  Because the bit-representation of a non-integral pointer may
+not be stable, two identical casts of the same operand may or may not
+return the same value.  Said differently, the conversion to or from the
+non-integral type depends on environmental state in an implementation
+defined manner.
+
+If the frontend wishes to observe a *particular* value following a cast, the
+generated IR must fence with the underlying environment in an implementation
+defined manner. (In practice, this tends to require ``noinline`` routines for
+such operations.)
+
+From the perspective of the optimizer, ``inttoptr`` and ``ptrtoint`` for
+non-integral types are analogous to ones on integral types with one
+key exception: the optimizer may not, in general, insert new occurrences of
+such casts.  If a new cast is inserted, the optimizer would need to either
+ensure that a) all possible values are valid, or b) appropriate fencing is
+inserted.  Since the appropriate fencing is implementation defined, the
+optimizer can't do the latter.  The former is challenging as many commonly
+expected properties, such as ``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for
+non-integral types.
 
 .. _globalvars:
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D104547.353029.patch
Type: text/x-patch
Size: 2107 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210618/6869120d/attachment-0001.bin>