-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[LangRef] Clarify that ptrtoint
behaves like a capturing bitcast
#139349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LangRef] Clarify that ptrtoint
behaves like a capturing bitcast
#139349
Conversation
Created using spr 1.3.6-beta.1
@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:
""""""""
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
… 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
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#139349
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#139349
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
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
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
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 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.