[PATCH] D43172: [SelectionDAG][ARM][X86] Teach PromoteIntRes_SETCC to do a better job picking the result type for the setcc.

[Craig Topper via Phabricator via llvm-commits]

craig.topper created this revision.
craig.topper added reviewers: RKSimon, spatel.
Herald added subscribers: kristof.beyls, javed.absar.

Previously if getSetccResultType returned an illegal type we just fell back to using the default promoted type. This appears to have been to handle the case where for vectors getSetccResultType returns the input type, but the input type itself isn't legal and will need to be promoted. Without the legality check we would never reach a legal type.

But just picking the promoted type to be the setcc type can create strange setccs where the result type is 128 bits and the operand type is 256 bits. If for example the result type was promoted to v8i16 from v8i1, but the input type was promoted from v8i23 to v8i32. We currently handle this with custom lowering code in X86.

This legality check also caused us reject the getSetccResultType when the input type needed to be widened or split. Even though that result wouldn't have caused legalization to get stuck.

This patch tries to fix this situation by detecting that the input type needs to be promoted and using the promoted input type to make the setcc call. This should prevent getting stuck always picking the same illegal type.

I tried legalizing the operands of the setcc at the same time as the result for this case, but that caused some test changes solely due to the next DAG combine running in a different order.

The x86 test changes look to be regressions. Previously we were rejecting this because the result type being returned was v8i64 but we were rejecting it in favor of v8i16. Then we split the operands to v4i64, created a setcc with v4i1 result type. Promoted that v4i1 to v4i32. Then split the setcc operands again to v2i64, created setcc with v2i1 result type. Then finally promoted that v2i1 result to v2i64. Each time we promote the result a truncate node gets introduced. Somehow those intermediate truncates helped us legalize this well. Now we keep v8i64 and always have vXi1 or vXi64 results for the setccs. We are able to split these setccs without introducing any new truncates.


Repository:
  rL LLVM

https://reviews.llvm.org/D43172

Files:
  lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
  lib/Target/X86/X86ISelLowering.cpp
  test/CodeGen/ARM/vuzp.ll
  test/CodeGen/X86/bitcast-and-setcc-512.ll
  test/CodeGen/X86/vector-compare-results.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D43172.133809.patch
Type: text/x-patch
Size: 46704 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180212/5201b54a/attachment.bin>