[PATCH] D148957: [AMDGPU] Add intrinsic for converting global pointers to resources

[Krzysztof Drewniak via Phabricator via llvm-commits]

krzysz00 added a comment.

Re the evil code: you're right, but I could also write that as

  %alloca = ...
  %cast = addrspacecast ptr addrspace(5) %alloca to ptr
  %as.int = ptrtoint ptr %cast as i64
  %ext = zext i64 %as.int to i128
  %buffer.int = or i128 %ext, i128 [...]
  ; Either
  %buffer = inttoptr i128 %buffer.int to ptr addrspace(8)
  ; or
  %buffer = bitcast i128 %buffer.int to <4 x i32>
  ; Muck around in everyone else's stack, etc etc.
  %buffer = call ptr addrspace(8) @llvm.amdgcn.as.buffer.rsrc.p0(ptr %cast ...)

As to what we should *do* about it ... I'm not 100% sure, but it seems to me that, from an IR perspective, this sort of cracking open the stack is allowed, but using it to step on something that's not in bounds of your pointer isn't.
So the conversion itself is valid, but you'd get `undef` (conceptually) from trying to read things you shouldn't.

In other words, I'd argue IR that takes `alloca()` results and builds the buffer manually is the same kind of syntactically unavoidable but semantically forbidden behavior as

  %alloca = alloca [1 x i8]
  %poke = getelementptr i8, ptr %alloca, i64 1024
  store i64 ..., ptr %poke

even though creating `%poke` itself is allowed (if I understand the semantics of LLVM IR correctly).



================
Comment at: llvm/include/llvm/IR/IntrinsicsAMDGPU.td:999
+// Use i8 type because we can't pull the element type out of an anyptr.
+def int_amdgcn_as_buffer_rsrc : DefaultAttrsIntrinsic <
+  [AMDGPUBufferRsrcTy<llvm_i8_ty>],
----------------
arsenm wrote:
> make_buffer_rsrc? as makes it sound like a regular cast?
I'm thinking of it as an `addrspacecast` that takes arguments, hence the naming, but I'm not too tied to the name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148957