[LangRef] Clarify that ptrtoint behaves like a capturing bitcast#139349
Merged
arichardson merged 1 commit intomainfrom May 20, 2025
Conversation
Created using spr 1.3.6-beta.1
Member
|
@llvm/pr-subscribers-llvm-ir Author: Alexander Richardson (arichardson) ChangesThis clarifies the outcome of the discussion in Full diff: https://github.com/llvm/llvm-project/pull/139349.diff 1 Files Affected:
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 7296bb84b7d95..bf38177d5d053 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -12396,12 +12396,15 @@ Semantics:
""""""""""
The '``ptrtoint``' instruction converts ``value`` to integer type
-``ty2`` by interpreting the pointer value as an integer and either
-truncating or zero extending that value to the size of the integer type.
+``ty2`` by interpreting the all pointer representation bits as an integer
+(equivalent to a ``bitcast``) and either truncating or zero extending that value
+to the size of the integer type.
If ``value`` is smaller than ``ty2`` then a zero extension is done. If
``value`` is larger than ``ty2`` then a truncation is done. If they are
the same size, then nothing is done (*no-op cast*) other than a type
change.
+The ``ptrtoint`` always :ref:`captures address and provenance <pointercapture>`
+of the pointer argument.
Example:
""""""""
@@ -12456,6 +12459,9 @@ of the integer ``value``. If ``value`` is larger than the size of a
pointer then a truncation is done. If ``value`` is smaller than the size
of a pointer then a zero extension is done. If they are the same size,
nothing is done (*no-op cast*).
+The behavior is equivalent to a ``bitcast``, however, the resulting value is not
+guaranteed to be dereferenceable (e.g. if the result type is a
+:ref:`non-integral pointers <nointptrtype>`).
Example:
""""""""
|
This was referenced May 12, 2025
llvm-sync Bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
May 20, 2025
… bitcast This clarifies the outcome of the discussion in https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54 In the future, we will also introduce a non-capturing pointer -> address conversion using a new `ptrtoaddr` instruction. Reviewed By: krzysz00 Pull Request: llvm/llvm-project#139349
arichardson
added a commit
that referenced
this pull request
Jun 11, 2025
While we can only reason about the index/address, the G_PTRTOINT operations returns all representation bits, so we can't assume the remaining ones are all zeroes. This behaviour was clarified as part of the discussion in https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54. The LangRef semantics of ptrtoint being a full representation bitcast were documented in #139349. Prior to 77c8d21 we were incorrectly assuming known zeroes beyond the index size even if the input was completely unknown. This commit adds a test case for G_PTRTOINT which was omitted from that change. See #139598 Reviewed By: arsenm Pull Request: #139608
llvm-sync Bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jun 11, 2025
While we can only reason about the index/address, the G_PTRTOINT operations returns all representation bits, so we can't assume the remaining ones are all zeroes. This behaviour was clarified as part of the discussion in https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54. The LangRef semantics of ptrtoint being a full representation bitcast were documented in llvm/llvm-project#139349. Prior to 77c8d21 we were incorrectly assuming known zeroes beyond the index size even if the input was completely unknown. This commit adds a test case for G_PTRTOINT which was omitted from that change. See llvm/llvm-project#139598 Reviewed By: arsenm Pull Request: llvm/llvm-project#139608
tomtor
pushed a commit
to tomtor/llvm-project
that referenced
this pull request
Jun 14, 2025
While we can only reason about the index/address, the G_PTRTOINT operations returns all representation bits, so we can't assume the remaining ones are all zeroes. This behaviour was clarified as part of the discussion in https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54. The LangRef semantics of ptrtoint being a full representation bitcast were documented in llvm#139349. Prior to 77c8d21 we were incorrectly assuming known zeroes beyond the index size even if the input was completely unknown. This commit adds a test case for G_PTRTOINT which was omitted from that change. See llvm#139598 Reviewed By: arsenm Pull Request: llvm#139608
akuhlens
pushed a commit
to akuhlens/llvm-project
that referenced
this pull request
Jun 24, 2025
While we can only reason about the index/address, the G_PTRTOINT operations returns all representation bits, so we can't assume the remaining ones are all zeroes. This behaviour was clarified as part of the discussion in https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54. The LangRef semantics of ptrtoint being a full representation bitcast were documented in llvm#139349. Prior to 77c8d21 we were incorrectly assuming known zeroes beyond the index size even if the input was completely unknown. This commit adds a test case for G_PTRTOINT which was omitted from that change. See llvm#139598 Reviewed By: arsenm Pull Request: llvm#139608
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This clarifies the outcome of the discussion in
https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987/54
In the future, we will also introduce a non-capturing pointer -> address
conversion using a new
ptrtoaddrinstruction.