[llvm-branch-commits] [AutoUpgrade][AMDGPU] Adjust AS7 address width to 48 bits (PR #137418)

[Alexander Richardson via llvm-branch-commits]

arichardson wrote:

> So p9 is quite weird. It's used, IIRC, by, https://github.com/GPUOpen-Drivers/llpc internally to represent "structured" pointers, and so its interpretation is `{p8 rsrc, i32 index, i32 offset}` . This does still have a 48-bit effective address by way of a thoroughly weird ptrtoaddr function that's, in it's full generality, a function of the resource flags (see swizzles)
> 
> As to ptrmask on p8 ... if ptrmask is only supposed to affect the Index bits, then I probably shouldn't be emitting it during the p7 => p8 process and only applying a mask to the offset. But that hits the same weirdness that masking for alignment doesn't work as expected if the base pointer isn't quite aligned enough.
> 
> (I can't think of many instances where that base pointer will, for example, be odd, but I'm not aware of anything saying it's not allowed. Though I'd personally be OK with documenting around that)
> 
> I think most codegen - including down in LLPC - assumes the base is at least `align 4`, which is the largest value where you sometimes need to change behavior, so you can quietly figure that the alignment of the offset is _basically_ the alignment of the pointer
> 

Thanks for all the background - how do you feel about pretending that p8 has a 48-bit index width until we figure out how to do "no indexing allowed" correctly?

> Actually, more general question on this address with stuff: x86 thread local storage. That's a form of pointer with an implicit base that can mess up your alignment checks - how's that work with ptrtoaddr?

Agreed, segmentation is awkward and I think we just have to assume that the segments are sufficiently aligned. I think this is somewhat outside of the LLVM abstract machine similar to page based memory. If we perform alignment checks on virtual addresses beyond 12/16/etc bits, there is no guarantee the final address will be sufficiently aligned but I view that as being outside of the LLVM semantics. I think we just have to pretend that virtual addresses or segment-relative addresses are the only thing that matters.



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