[AVX512] LLVM ERROR: Cannot select: t54: v8f64 = vselect t46, undef:v8f64, t17

[dbabokin]

Bugzilla Link	34139
Resolution	FIXED
Resolved on	Aug 23, 2017 13:04
Version	trunk
OS	All
Blocks	#33196
Attachments	reproducer before test case reduction
CC	@dbabokin,@topperc,@Delena,@zmodem,@igor-breger,@RKSimon,@JonPsson,@ZviRackover

Extended Description

clang version 6.0.0 (trunk 310421)

cat bugpoint-reduced-simplified.ll
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "bugpoint-output-19a0c4b.bc"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: nounwind
define void @​f_f() #​0 {
allocas:
store <16 x i8> <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>, <16 x i8>* undef
%load_mask8.i.i.i = load <16 x i8>, <16 x i8>* undef
%v.i.i.i.i = load <16 x double>, <16 x double>* undef
%mask_vec_i1.i.i.i51.i.i = icmp ne <16 x i8> %load_mask8.i.i.i, zeroinitializer
%v1.i.i.i.i = select <16 x i1> %mask_vec_i1.i.i.i51.i.i, <16 x double> undef, <16 x double> %v.i.i.i.i
store <16 x double> %v1.i.i.i.i, <16 x double>* undef
unreachable
}

attributes #​0 = { nounwind }

!llvm.module.flags = !{#0}

!​0 = !{i32 1, !"wchar_size", i32 4}

llc -O2 -mcpu=knl bugpoint-reduced-simplified.bc
LLVM ERROR: Cannot select: t54: v8f64 = vselect t46, undef:v8f64, t17
t46: v8i64 = bitcast t45
t45: v16i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t44: i32 = Constant<-1>
t16: v8f64 = undef
t17: v8f64,ch = load<LD64undef(align=128)+64> t49, undef:i64, undef:i64
t3: i64 = undef
t3: i64 = undef
In function: f_f

[llvmbot]

bisected to r297930

https://reviews.llvm.org/rL297930

[zmodem]

bisected to r297930

https://reviews.llvm.org/rL297930

Potential 5.0 blocker, then.

[JonPsson]

I see that after

Type-legalized selection DAG: BB#0 'f_f:allocas'
SelectionDAG has 19 nodes:
t2: v16i8 = BUILD_VECTOR Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>
, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>, Constant:i8<-1>
t0: ch = EntryToken
t5: ch = store<ST16[undef]> t0, t2, undef:i64, undef:i64
t17: v8f64,ch = load<LD64undef(align=128)+64> t5, undef:i64, undef:i64
t28: v16i16 = sign_extend t2
t29: v8i16 = extract_subvector t28, Constant:i64<0>
t31: v8i64 = sign_extend t29
t26: v8f64 = vselect t31, undef:v8f64, t17
t33: ch = store<ST64undef> t17:1, t26, undef:i64, undef:i64
t30: v8i16 = extract_subvector t28, Constant:i64<8>
t32: v8i64 = sign_extend t30
t27: v8f64 = vselect t32, undef:v8f64, t17
t34: ch = store<ST64undef(align=128)+64> t17:1, t27, undef:i64, undef:i64
t35: ch = TokenFactor t33, t34

, there are vselects in the DAG, but after

Optimized legalized selection DAG: BB#0 'f_f:allocas'
SelectionDAG has 11 nodes:
t0: ch = EntryToken
t47: v4i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>
t49: ch = store<ST16[undef]> t0, t47, undef:i64, undef:i64
t17: v8f64,ch = load<LD64undef(align=128)+64> t49, undef:i64, undef:i64
t45: v16i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>, Constant:i32<-1>
t46: v8i64 = bitcast t45
t39: v8f64 = X86ISD::SHRUNKBLEND t46, undef:v8f64, t17
t34: ch = store<ST64undef(align=128)+64> t17:1, t39, undef:i64, undef:i64

, they are gone. A "SHRUNKBLEND" seems to have replaced one of the vselects. Don't know where the other vselect went, or the other store, which seems supsicious (DAG optimization removing a store?)

Then, during isel, a vselect appears again:

ISEL: Starting pattern match on root node: t54: v8f64 = vselect t46, undef:v8f64, t17

Where did this node come from? Why is it not in the final DAG before isel?

ISel fails with this node with

LVM ERROR: Cannot select: t54: v8f64 = vselect t46, undef:v8f64, t17

The operands are v8f64. Are there really such a vector instruction on X86/knl?

I could be wrong, but I am guessing there might be some DAG optimization that is messing up things at the point where the vselects are handled and a SHRUNKBLEND appears instead (type legalization). Not familiar at all with the X86 backend, though.

[topperc]

When isel sees a SHRUNKBLEND as the root of the pattern to match, X86ISelDAGToDAG.cpp will convert the SHRUNKBLEND back into a vselect. This was done so that we didn't need isel patterns for both SHRUNKBLEND and vselect. SHRUNKBLEND exists to hide a vselect from some transformation.

[topperc]

Patch submitted for review

https://reviews.llvm.org/D36992

[topperc]

Fixed in r311572

[zmodem]

Fixed in r311572

Merged in r311593. Thanks!