[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