AMDGPU/GlobalISel: Select V_ADD3_U32/V_XOR3_B32
authorMatt Arsenault <Matthew.Arsenault@amd.com>
Wed, 22 Jan 2020 03:46:43 +0000 (22:46 -0500)
committerMatt Arsenault <arsenm2@gmail.com>
Thu, 23 Jan 2020 17:04:20 +0000 (12:04 -0500)
commit618fa77ae4dd8244e468fce0bf144fa329f41e5b
tree9080ada2af199f2bf0d7029cb11a5aeca81ba1c4
parent4faf71a14338420afc09eec261d5295439ae956a
AMDGPU/GlobalISel: Select V_ADD3_U32/V_XOR3_B32

The other 3-op patterns should also be theoretically handled, but
currently there's a bug in the inferred pattern complexity.

I'm not sure what the error handling strategy should be for potential
constant bus violations. I think the correct strategy is to never
produce mixed SGPR and VGPR operands in a typical VOP instruction,
which will trivially avoid them. However, it's possible to still have
hand written MIR (or erroneously transformed code) with these
operands. When these fold, the restriction will be violated. We
currently don't have any verifiers for reg bank legality. For now,
just ignore the restriction.

It might be worth triggering a DAG fallback on verifier error.
llvm/lib/Target/AMDGPU/VOP3Instructions.td
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-add.mir
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-pattern-add3.mir [new file with mode: 0644]
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-pattern-or3.mir [new file with mode: 0644]
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-pattern-xor3.mir [new file with mode: 0644]
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-pattern-xor3.xfail.mir [new file with mode: 0644]
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.atomic.inc.ll
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.private.ll
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.is.shared.ll
llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.update.dpp.ll