krzysz00 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 --- 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? https://github.com/llvm/llvm-project/pull/137418 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
