[PATCH] D143945: [AMDGPU] Add legalization case for PTR_ADD on buffer pointers

[Krzysztof Drewniak via Phabricator via llvm-commits]

krzysz00 added a comment.

Ok, to elaborate the proposal - which is wonky enough that going `i160` might be the right call here, even though we don't have a `s_load_dwordx5` and so we'd need something like that buffer pointer launder intrinsic - is that  (given that we replace all `G_LOAD` with a `G_OFFSET_LOAD`) we replace

  %y = G_PTR_ADD p7 %x, s32 %a
  %v = G_OFFSET_LOAD p7 %y, s32 %b

with

  %newOff = G_ADD s32 %a, s32 %b
  %v = G_OFFSET_LOAD p7 %x, s32 %newOff

. If we get to select/phi, we duplicate those into select/phi on the offset and select/phi on the base pointer, and if we start storing things, we materialize the offset by incrementing the base address in the descriptor and then decrementing the buffer extent by the same amount.

But, having written that out, `i160` and having a `<4 x i32>/i128/...` to address space 7 intrinsic - or even not needing one, since `inttoptr` exists - may well be the better approach here.

The catch, I think, will be *when* we split away the offset part and the pointer part during ISel - and whether then it'll be too late to run uniformity analysis on the pointer part.

... on the third hand, the "increment address, decrement extent" fallback for GEPs that don't merge into a load or store isn't _that_ absurd


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143945/new/

https://reviews.llvm.org/D143945