[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