OSDN Git Service

[X86] Add isel pattern infrastructure to begin recognizing when we're inserting 0s...
authorCraig Topper <craig.topper@intel.com>
Fri, 15 Sep 2017 17:09:00 +0000 (17:09 +0000)
committerCraig Topper <craig.topper@intel.com>
Fri, 15 Sep 2017 17:09:00 +0000 (17:09 +0000)
commit566eb704ab3e2684c28f1de3b951e5a6d142a410
tree2466fd2b20746d74f0755adc837bc614754911b6
parent3c71a6c431256f097c433c1ae1afd22935dc2b7a
[X86] Add isel pattern infrastructure to begin recognizing when we're inserting 0s into the upper portions of a vector register and the producing instruction as already produced the zeros.

Currently if we're inserting 0s into the upper elements of a vector register we insert an explicit move of the smaller register to implicitly zero the upper bits. But if we can prove that they are already zero we can skip that. This is based on a similar idea of what we do to avoid emitting explicit zero extends for GR32->GR64.

Unfortunately, this is harder for vector registers because there are several opcodes that don't have VEX equivalent instructions, but can write to XMM registers. Among these are SHA instructions and a MMX->XMM move. Bitcasts can also get in the way.

So for now I'm starting with explicitly allowing only VPMADDWD because we emit zeros in combineLoopMAddPattern. So that is placing extra instruction into the reduction loop.

I'd like to allow PSADBW as well after D37453, but that's currently blocked by a bitcast. We either need to peek through bitcasts or canonicalize insert_subvectors with zeros to remove bitcasts on the value being inserted.

Longer term we should probably have a cleanup pass that removes superfluous zeroing moves even when the producer is in another basic block which is something these isel tricks can't do. See PR32544.

Differential Revision: https://reviews.llvm.org/D37653

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313365 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86InstrVecCompiler.td
test/CodeGen/X86/madd.ll