[PATCH] D36992: [AVX512] Don't create SHRUNKBLEND SDNodes for 512-bit vectors.x

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: lib/Target/X86/X86ISelLowering.cpp:30679
 
   // Look for vselects with LHS/RHS being bitcasted from an operation that
   // can be executed on another type. Push the bitcast to the inputs of
----------------
zvi wrote:
> Any chance that due to the added bail-out we will be missing out on this combine?
This combine runs on the very last DAG combine. The one above runs on earlier DAG combine. So I don't think there's an issue. If there was, I think the early out on BitWidth==1 above would be much worse.


================
Comment at: test/CodeGen/X86/pr34139.ll:13
+; CHECK-NEXT:    vmovapd %zmm0, %zmm1 {%k1}
+; CHECK-NEXT:    vmovapd %zmm1, (%rax)
+  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
----------------
delena wrote:
> Could you, please, explain me how <16 x double> value is stored using one ZMM instruction? 
I think its because the IR is using a store to undef as its address. So I think we sort of merged the stores. If i put in a real address we get two stores. I'll try to unreduce the test case a little


https://reviews.llvm.org/D36992