[PATCH] D72407: TableGen/GlobalISel: Add way for SDNodeXForm to work on timm

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 8 12:23:41 PST 2020


arsenm created this revision.
arsenm added reviewers: dsanders, paquette, aemerson, aditya_nandakumar.
Herald added subscribers: herhut, Petar.Avramovic, hiraditya, rovka, nhaehnle, wdng, jvesely.
Herald added a project: LLVM.

The current implementation assumes there is an instruction associated
with the transform, but this is not the case for
timm/TargetConstant/immarg values. These transforms should directly
operate on a specific MachineOperand in the source
instruction. TableGen would assert if you attempted to define an
equivalent GISDNodeXFormEquiv using timm when it failed to find the
instruction matcher.

      

Specially recognize SDNodeXForms on timm, and pass the operand index
to the render function.

     

Ideally this would be a separate render function type that looks like
void renderFoo(MachineInstrBuilder, const MachineOperand&), but this
proved to be somewhat mechanically painful. Add an optional operand
index which will only be passed if the transform should only look at
the one source operand.

      

Theoretically it would also be possible to only ever pass the
MachineOperand, and the existing renderers would check the parent. I
think that would be somewhat ugly for the standard usage which may
want to inspect other operands, and I also think MachineOperand should
eventually not carry a pointer to the parent instruction.

      

Use it in one sample pattern. This isn't a great example, since the
transform exists to satisfy DAG type constraints. This could also be
avoided by just changing the MachineInstr's arbitrary choice of
operand type from i16 to i32. Other patterns have nontrivial uses, but
this serves as the simplest example.

      

One flaw this still has is if you try to use an SDNodeXForm defined
for imm, but the source pattern uses timm, you still see the "Failed
to lookup instruction" assert. However, there is now a way to avoid
it.


https://reviews.llvm.org/D72407

Files:
  llvm/include/llvm/CodeGen/GlobalISel/InstructionSelector.h
  llvm/include/llvm/CodeGen/GlobalISel/InstructionSelectorImpl.h
  llvm/include/llvm/Target/GlobalISel/Target.td
  llvm/lib/Target/AArch64/AArch64InstructionSelector.cpp
  llvm/lib/Target/AMDGPU/AMDGPUGISel.td
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.h
  llvm/lib/Target/AMDGPU/DSInstructions.td
  llvm/lib/Target/AMDGPU/SIInstrInfo.td
  llvm/lib/Target/ARM/ARMInstructionSelector.cpp
  llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-amdgcn.ds.swizzle.mir
  llvm/test/TableGen/GlobalISelEmitter-SDNodeXForm-timm.td
  llvm/utils/TableGen/GlobalISelEmitter.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D72407.236882.patch
Type: text/x-patch
Size: 19075 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200108/06ef2bee/attachment.bin>


More information about the llvm-commits mailing list