[llvm] [llvm][docs] Expand section on non-integral pointers (PR #73242)
via llvm-commits
llvm-commits at lists.llvm.org
Mon Dec 4 17:01:36 PST 2023
================
@@ -634,6 +634,12 @@ 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.
+Similar restrictions apply to intrinsics that might examine the pointer bits,
+such as :ref:`llvm.ptrmask<int_ptrmask>`. In particular, it's not
+correct to infer `align` attributes for such pointers based on examining their
+bits and frontends must ensure that all `align` attributes represent the
+conservative alignment valid for every possible representation of the pointer.
+
----------------
arpilipe wrote:
```suggestion
challenging as many commonly expected properties, such as
``ptrtoint(v)-ptrtoint(v) == 0``, don't hold for non-integral types.
Similar restrictions apply to intrinsics that might examine the pointer bits,
such as :ref:`llvm.ptrmask<int_ptrmask>`.
The alignment information provided by the frontend for a non-integral pointer
(typically using attributes or metadata) must be valid for every possible
representation of the pointer.
```
I intentionally dropped this part:
"In particular, it's not correct to infer `align` attributes for such pointers based on examining their bits"
This is because the section above allows inspection of the bitwise value when properly fencing with the underlying environment.
https://github.com/llvm/llvm-project/pull/73242
More information about the llvm-commits
mailing list