[X86] Fix a regression caused by moving combineLoopMAddPattern to IR
authorCraig Topper <craig.topper@intel.com>
Thu, 14 May 2020 17:06:07 +0000 (10:06 -0700)
committerCraig Topper <craig.topper@intel.com>
Thu, 14 May 2020 17:31:28 +0000 (10:31 -0700)
commit2b0b9b1148c205dfd73c70d195f51ef9895e2307
tree4fd7128220bdc22c318e2c6c7ecd97eb0d15c0bc
parentacb6f1ae096e8262fb30a267e9f40dea62432b26
[X86] Fix a regression caused by moving combineLoopMAddPattern to IR

When I moved combineLoopMAddPattern to an IR pass. I didn't match the behavior of canReduceVMulWidth that was used in the SelectionDAG version. canReduceVMulWidth just calls computeSignBits and assumes a truncate is always profitable. The version I put in IR just looks for constants and zext/sext. Though I neglected to check the number of bits in input of the zext/sext.

This patch adds a check for the number of input bits to the sext/zext. And it adds a special case for add/sub with zext/sext inputs which can be handled by combineTruncatedArithmetic. Match the original SelectionDAG behavior appears to be a regression in some cases if the truncate isn't removed and becomes pack and permq. So enabling only this specific case is the conservative approach.

Differential Revision: https://reviews.llvm.org/D79909
llvm/lib/Target/X86/X86PartialReduction.cpp
llvm/test/CodeGen/X86/madd.ll