[PATCH] D45994: AMDGPU/GlobalISel: Enable TableGen'd instruction selector

Tom Stellard via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 9 07:21:29 PDT 2018


tstellar added inline comments.


================
Comment at: lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp:478
+AMDGPUInstructionSelector::selectVSRC0(MachineOperand &Root) const {
+  auto Res = selectImm(Root);
+  if (Res != None)
----------------
nhaehnle wrote:
> arsenm wrote:
> > We don't fold immediates in the DAG selector now, so why do this here?
> In fact, I remember there are some edge cases where folding immediates directly doesn't work due to moveToVALU. Basically, if you initially generate an instruction like S_ADD with an immediate and that instruction then gets moved to VALU it becomes a VOP3-encoded V_ADD which cannot have an immediate (because of the restriction that instructions can be at most 64 bits long), leading to machine instruction verifier errors.
> 
> The question is whether the same issue may apply here when going through GlobalISel in corner cases, even if we try to be better at selection the correct ALU directly. I think it makes sense to be a bit conservative initially.
> We don't fold immediates in the DAG selector now, so why do this here?

Because we can?  Ideally doing folding in during ISel would allow us to eliminate or greatly simplify the SIFoldOperands pass, but admittedly, global-isel is so new I don't know if that would be possible.   I can go either way on folding during ISel, but it would at least be nice to have a target feature to enable this.

How do you feel about selecting directly to _e32 variants when we can instead of _e64, which also something that global-isel is doing?








Repository:
  rL LLVM

https://reviews.llvm.org/D45994





More information about the llvm-commits mailing list