[PATCH] D94645: [AMDGPU] Fix llvm.amdgcn.init.exec and frame materialization

Ruiling, Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 15 00:52:29 PST 2021


ruiling added inline comments.


================
Comment at: llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:1916
+    // Update insertion point
+    if (!FirstMI)
+      FirstMI = &*MBB.begin();
----------------
critson wrote:
> ruiling wrote:
> > In case the FirstMI is not null, which means a COPY instruction to copy from input register was not eliminated for some reason, we need to move the COPY instruction to the beginning of the block and insert exec initialization right after that. Because the frame-base materialization instructions may be inserted before the COPY instruction. We need to make sure the exec initialization always be inserted at the entry of the block.
> I only partially agree with this.
> In theory the input to the intrinsic can be any operation -- unless we refine its definition (which I am not against doing).
> So in the general case we cannot move this operation before the instruction which generates its input.
> If we are saying that the input to this register is always a live-in, then we shouldn't be moving the COPY, rather we should be using the source of the COPY as the source of this operation directly.
what I said is the most common case  at MachineIR. a Copy from funtion input, then init.exec.from.input with the Copy destination. I think no frontend will generate the argument to init.exec.with.input with arbitray operation. I am not saying moving operation before the instruction that generates the input to the operation. The general idea is we need to ensure the instructions to set the EXEC should be before any vector instruction. Based on this, we should move all instructions in the define-use chain of the input to init.exec.with.input to block entry to be before all vector instructions. In practice, your suggestion to use the Copy' source should work because that's the only usage the frontend will generate. The existing implementation before your change already assume Copy is the only possible operation that generates input to this intrinsic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94645



More information about the llvm-commits mailing list