[llvm] [llvm][docs] Expand section on non-integral pointers (PR #73242)

[Danila Malyutin via llvm-commits]

https://github.com/danilaml updated https://github.com/llvm/llvm-project/pull/73242

>From 1ac0e4809970e5a53cb5bbf6084526f222af4b54 Mon Sep 17 00:00:00 2001
From: Danila Malyutin <dmalyutin at azul.com>
Date: Thu, 23 Nov 2023 17:37:05 +0400
Subject: [PATCH 1/2] [llvm][docs] Expand section on non-integral pointers

Specify their restrictions w.r.t. `align` attribute.
---
 llvm/docs/LangRef.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index bc1eab1e0b7a0..1958a3cb0d75e 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -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.
+
 .. _globalvars:
 
 Global Variables

>From 23600db79ab6499907a1e2f1770c5d2f218a238f Mon Sep 17 00:00:00 2001
From: Danila Malyutin <danilaml at users.noreply.github.com>
Date: Tue, 5 Dec 2023 10:31:48 +0300
Subject: [PATCH 2/2] Update llvm/docs/LangRef.rst

Co-authored-by: arpilipe <apilipenko at azul.com>
---
 llvm/docs/LangRef.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 1958a3cb0d75e..cdbdd758d35a3 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -633,12 +633,12 @@ appropriate fencing is inserted.  Since the appropriate fencing is
 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.
+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.
 
 .. _globalvars: