[llvm] [DataLayout] Introduce DataLayout::getPointerAddressSize(AS) (PR #137412)

[Alexander Richardson via llvm-commits]

================
@@ -3147,14 +3147,20 @@ as follows:
 ``A<address space>``
     Specifies the address space of objects created by '``alloca``'.
     Defaults to the default address space of 0.
-``p[n]:<size>:<abi>[:<pref>][:<idx>]``
+``p[n]:<size>:<abi>[:<pref>[:<idx>[:<addr>]]]``
     This specifies the *size* of a pointer and its ``<abi>`` and
     ``<pref>``\erred alignments for address space ``n``.
-    The fourth parameter ``<idx>`` is the size of the
-    index that used for address calculation, which must be less than or equal
-    to the pointer size. If not
-    specified, the default index size is equal to the pointer size. All sizes
-    are in bits. The address space, ``n``, is optional, and if not specified,
+    The fourth parameter ``<idx>`` is the size of the index that used for
+    address calculations such as :ref:`getelementptr <i_getelementptr>`.
+    It must be less than or equal to the pointer size. If not specified, the
+    default index size is equal to the pointer size.
+    The fifth parameter ``<addr>`` specifies the width of addresses in this
+    address space. If not specified, the default address size is equal to the
+    index size. The address size may be wider than the index size as it could be
+    calculated relative to a base address. For example AMDGPU buffer fat
+    pointers use a 48-bit address range, but only allow for 32 bits of indexing.
----------------
arichardson wrote:

I imagine that within the stack address space you have 32-bit range and the 32-bit offset from the fixed base uniquely identifies the underlying address?
In that case I don't think you'd need to expose the underlying "real address" for `ptrtoaddr`. I'd view that as being similar to running a 32-bit program on 64-bit kernel where the virtual memory system translates those 32-bit addresses to a final 64 (well likely less) bit physical address.

I'm not sure if there is any advantage in exposing the 48-bit (?) final address, but if you think there is we can definitely relax this restriction.

https://github.com/llvm/llvm-project/pull/137412