The "name" of a non-leaf complex pattern (MY_PAT $op1, $op2) is
"MY_PAT:op1:op2" and the ones with same "name" represent same operand.
Add 'same operand check' for this case.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
How does the new test case relate to the tablegen change? Perhaps you could pre-commit it so we can see the test case diffs?
Show how this emitter change affects isel, and update tablegen tests.
Add additional checks for complex suboperands for test added in D57980. Neither tablegen nor sdag have check for such pattern and it looks like an error to me (there is no way for tablegen to know that some c++ code that generates two operands will generate same operand x (first out operand) from different input operands - these are operand 1 and 2 of G_ADD instruction). Also, if I checked correctly, there were no patterns like that in llvm upstream. Skip such patterns anyway in GlobalIselEmitter.
Can you add tests for the min3/max3/med3 patterns? I think this is what was blocking those
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-fract.f64.mir | ||
---|---|---|
27–28 | Is this pattern really correct? It should probably be moved into a combine instead of a selection pattern if so |
min3/max3 patterns are handled in combiner, inducing med3 patterns with constants. Patch imports med3 isel patterns: min(max(a, b), max(min(a, b), c)) but they need some combines/legalize fixes to be selected. From new imports only V_FRACT can be selected at the moment.
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-fract.f64.mir | ||
---|---|---|
27–28 | It is correctly selected since -enable-unsafe-fp-math flag was on. |
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-fract.f64.mir | ||
---|---|---|
27–28 | I think this should be moved into a combine and not depend on the global flag, but that's a separate change |
Is this pattern really correct? It should probably be moved into a combine instead of a selection pattern if so