Unable to select BUILD_VECTOR operation

[llvmbot]

Bugzilla Link	9165
Resolution	FIXED
Resolved on	Feb 12, 2011 08:44
Version	trunk
OS	All
Attachments	LL file reproducing the problem
Reporter	LLVM Bugzilla Contributor
CC	@nadavrot

Extended Description

When codegen the attached LL file using LLC, we hit the following problem.

This is a regression from 2.7. I have a fix ready for this in the DAGCombiner, pending managerial approval. Will send a patch to the LLVM-commit soon.

LLVM ERROR: Cannot select: 0x1dfa9e0: v4i32 = BUILD_VECTOR 0x1dfa3e0, 0x1e044a0, 0x1df9fe0, 0x1e045a0 [ID=30]
0x1dfa3e0: i32 = Constant<0> [ORD=1] [ID=1]
0x1e044a0: i32 = extract_vector_elt 0x1e03690, 0x1e03b90 [ID=26]
0x1e03690: v4i32 = bit_convert 0x1e04da0 [ID=21]
0x1e04da0: v2i64,ch = load 0x1dcb0b8, 0x1e03490, 0x1df9fe0<LD16null+32> [ID=17]
0x1dcb0b8: ch = EntryToken [ORD=1] [ID=0]
0x1e03490: i32 = Constant<32> [ID=4]
0x1df9fe0: i32 = undef [ORD=1] [ID=2]
0x1e03b90: i32 = Constant<1> [ID=5]
0x1df9fe0: i32 = undef [ORD=1] [ID=2]
0x1e045a0: i32 = extract_vector_elt 0x1e05600, 0x1e03b90 [ID=24]
0x1e05600: v4i32 = bit_convert 0x1dfa2e0 [ID=19]
0x1dfa2e0: v2i64,ch = load 0x1dcb0b8, 0x1dfa3e0, 0x1df9fe0<LD16null> [ID=14]
0x1dcb0b8: ch = EntryToken [ORD=1] [ID=0]
0x1dfa3e0: i32 = Constant<0> [ORD=1] [ID=1]
0x1df9fe0: i32 = undef [ORD=1] [ID=2]
0x1e03b90: i32 = Constant<1> [ID=5]

[llvmbot]

The problem appeared between 2.7 and 2.8 and is still in the LLVM trunk.
After the 2.7 release some code was added in X86ISelLowering:

// For SSE 4.1, use insertps to put the high elements into the low element.
if (getSubtarget()->hasSSE41()) {
...

This optimization created a new pattern, which was previously unknown to man! The pattern was a lowering of the BUILD_VECTOR operation to a sequence of simple BUILD_VECTOR (all zero or undef) and a sequence of insert-elements. The next stage, the DAGCombining, is the last stage before the instruction selection. This phase found the new pattern and created a complex BUILD_VECTOR, which was illegal. The last-phase dag-combining is only allowed to create legal instructions. In my patch I added a check that the new pattern is only optimized if we are in the LegalOperations mode, which is allowed to crate illegal instructions such as the one we encountered.

Patch:

Index: DAGCombiner.cpp

--- DAGCombiner.cpp (revision 124985)
+++ DAGCombiner.cpp (working copy)
@@ -6377,7 +6377,8 @@

// If the invec is a BUILD_VECTOR and if EltNo is a constant, build a new
// vector with the inserted element.

• if (InVec.getOpcode() == ISD::BUILD_VECTOR && isa(EltNo)) {

• if (!LegalOperations && InVec.getOpcode() == ISD::BUILD_VECTOR &&

•  isa<ConstantSDNode>(EltNo)) {
  

  unsigned Elt = cast(EltNo)->getZExtValue();
  SmallVector<SDValue, 8> Ops(InVec.getNode()->op_begin(),
  InVec.getNode()->op_end());

[llvmbot]

Shouldn't the patch check that either !LegalOperations or that the operation it
is creating is legal?

[llvmbot]

Fixed in 125435.
Accepted Duncan's comment and added a check if the generated type is legal.