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

[Philip Reames via Phabricator via llvm-commits]

reames added inline comments.


================
Comment at: llvm/docs/LangRef.rst:608
+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
----------------
mkazantsev wrote:
> What about same cast of the same operand executed twice (e.g. in a loop)? Is it possible that it produces different values twice, and therefore LICM of the cast is illegal?
They could produce two different values, but unless fenced (in some unspecified implementation dependent manner), they're allowed to return a single value and thus LICM is legal.


================
Comment at: llvm/docs/LangRef.rst:620
+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
----------------
mkazantsev wrote:
> Does this also apply to such things as unrolling and unswitching? Sounds over-restrictive.
This is a good question.  I had not intended to disallow unrolling, but I can see how the current wording reads that way.

If I tweaked the wording to say that the optimizer isn't allowed to insert new *dynamic* occurrences of the cast, would that address the concern?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104547