[PATCH] D143945: [AMDGPU] Add legalization case for PTR_ADD on buffer pointers
Krzysztof Drewniak via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 14 09:15:27 PST 2023
krzysz00 added a subscriber: sheredom.
krzysz00 added a comment.
@piotr @nhaehnle @sheredom My proposal here - and in the patch stack in general, is that we do revisit that 160-bit idea.
How I imagine this working is that, if you GEP a buffer descriptor, the operation that that lowers to - here `G_PTR_ADD` - does not modify the input buffer descriptor value at all. Instead, all these offsets we add are accumulated into the `voffset` and `imm` fields of the relevant `MUBUF` instruction.
That means that
%y = gep i32, ptr addrspace(7) %x, i32 1
%z = load i32, ptr addrspace(7) %y
lowers to
[%z] = BUFFER_LOAD_DWORD [%x], offset:4
and any pattern of code that can't be translated into offsets on a load/store/atomic is unsupported.
Now, this does mean that, for example
%y = gep i32 ptr addrspace(7) %x, i32 1
%z = ptrtoint i128 %y
produces ... who the heck knows what ... in `%z`, but buffer descriptors are a very weird kind of pointer and anyone emitting such code either knows exactly what they're doing or is Wrong. (My gut tells me that, if I _had_ to pick a behavior, `ptrtoint %y == ptrtoint %x`)
Now, in the case that the buffer descriptor itself in non-uniform, I'm willing to initially declare that case a "instruction selection failed" case and perhaps add emulation in the future.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D143945/new/
https://reviews.llvm.org/D143945
More information about the llvm-commits
mailing list