[PATCH] D128839: [DirectX backend] Add createHandle BufferLoad/Store DXIL operation

Chris Bieneman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 30 06:24:37 PDT 2022


beanz added inline comments.


================
Comment at: llvm/include/llvm/IR/IntrinsicsDXIL.td:22
+
+def int_dxil_buffer_load : Intrinsic<[ llvm_any_ty, LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>, llvm_i32_ty ],
+ [ llvm_i64_ty, llvm_i32_ty, llvm_i32_ty], [IntrReadMem, IntrWillReturn]>;
----------------
python3kgae wrote:
> beanz wrote:
> > python3kgae wrote:
> > > beanz wrote:
> > > > Do you have a plan for taking LLVM load instructions and converting them to these intrinsics?
> > > > 
> > > > I think we need to think about how we want to translate LLVM gep/load/store instructions into DXIL ops, and I don't think we should add these intrinsics until we know what that is going to look like.
> > > These intrinsics are trying to make the distance from hlsl to DXIL shorter.
> > > They're just wrapper for DXIL operation functions so generate DXIL is easier.
> > > 
> > >  I did experiment to generate DXIL directly from GEP/load/store, then found create intrinsic might help the translation.
> > I still don't know that these are the _right_ intrinsics. How are we going to map GEP/load/store to these intrinsics?
> It will not be a simple map, we'll need a pass to translate GEP/load/store to these intrinsics.
> These intrinsics are to make the pass easier to write and leave the details like DXIL opcode, DXIL struct type to DXILOpLowering pass.
> 
> Maybe we can allow GEP/load/store in final DXIL for future DXIL version, but to generate early version of DXIL, these intrinsics will be 
>  helpful.
I didn't mean to imply it would be a simple map (as in map data structure), but it is a mapping operation. GEPs get folded in with loads and stores to form load and store DXIL Ops.

Clang will generate GEPs, loads, and stores through known handle pointers. Unlike in DXC we won't map those to "high level" intrinsics during codegen, instead we'll emit the GEPs, loads and stores. That will allow LLVM's optimization passes (like SROA) to run without needing to be taught about all of the special intrinsics for HLSL.

If the input to our backend is expected to be GEPs, loads and stores, I fail to see why we would translate those to an intrinsic that has an identical signature to the DXIL Op (minus the opcode) instead of just translating it to the DXIL Op directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128839



More information about the llvm-commits mailing list