[PATCH] D13505: [X86] Fix bad treatment of multi-lane blends in BUILD_VECTORtoBlendMask()

[Andrea Di Biagio via llvm-commits]

andreadb added a comment.

In http://reviews.llvm.org/D13505#261765, @filcab wrote:

> I have a question:
>  This looks like it's to generate BLENDI nodes, in order to match the Intel instructions for blends with immediates...
>  But there are no byte-shuffles with immediates, AFAICT.
>
> What did I miss?


The user of that function delegates the selection of shuffle blend nodes to the shuffle lowering logic.
That said, you are right and there are no byte shuffles with immediate mask. However, I don't think it is in general a bad idea to canonicalize byte shuffles to shuffle vector node since it may potentially enable more combining of shuffles.


================
Comment at: test/CodeGen/X86/vector-blend.ll:664
@@ +663,3 @@
+; AVX1-NEXT:    vextractf128    $1, %ymm0, %xmm3
+; AVX1-NEXT:    vmovdqa .LCPI18_0(%rip), %xmm4  # xmm4 = [255,255,0,255,0,0,0,255,255,255,0,255,0,0,0,255]
+; AVX1-NEXT:    vpblendvb       %xmm4, %xmm2, %xmm3, %xmm2
----------------
filcab wrote:
> Why are the "first lanes" changing here? Either it was completely wrong, and you're fixing it, or the replacement is wrong (the "second lane" was always wrong).
The operands to the vpblendvb have been commuted. So the mask has been changed accordingly. I don't think this is wrong.


http://reviews.llvm.org/D13505