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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
