]> granicus.if.org Git - llvm/commit
[X86] Don't a vzext_movl in LowerBuildVectorv16i8/LowerBuildVectorv8i16 if there...
authorCraig Topper <craig.topper@intel.com>
Mon, 24 Jun 2019 17:28:41 +0000 (17:28 +0000)
committerCraig Topper <craig.topper@intel.com>
Mon, 24 Jun 2019 17:28:41 +0000 (17:28 +0000)
commitb85f7201ba1b9a9092a3bb437cbc27b063a604a4
tree603827190b102407e2b012ab1ec51c3b12225c35
parent172944c965d443c4902f4a5004f5d871c53f77c7
[X86] Don't a vzext_movl in LowerBuildVectorv16i8/LowerBuildVectorv8i16 if there are no zeroes in the vector we're building.

In LowerBuildVectorv16i8 we took care to use an any_extend if the first pair is in the lower 16-bits of the vector and no elements are 0. So bits [31:16] will be undefined. But we still emitted a vzext_movl to ensure that bits [127:32] are 0. If we don't need any zeroes we should be consistent and make all of 127:16 undefined.

In LowerBuildVectorv8i16 we can just delete the vzext_movl code because we only use the scalar_to_vector when there are no zeroes. So the vzext_movl is always unnecessary.

Found while investigating whether (vzext_movl (scalar_to_vector (loadi32)) patterns are necessary. At least one of the cases where they were necessary was where the loadi32 matched 32-bit aligned 16-bit extload. Seemed weird that we required vzext_movl for that case.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364207 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86ISelLowering.cpp