<div dir="ltr"><div>Nice patch Simon!<br><br></div>Please see my comment inline.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 9:54 AM, Simon Pilgrim <span dir="ltr"><<a href="mailto:llvm-dev@redking.me.uk" target="_blank">llvm-dev@redking.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Author: rksimon<br>
Date: Tue Jul 28 03:54:41 2015<br>
New Revision: 243395<br>
<br>
URL: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D243395-26view-3Drev&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=ouU319mGCM_P2i5-yLUsQY5zONEW0SFpxh6K3mi8opc&s=3FWTNKgyycxqZ9SaYnqQkGLc_Pls8JvaqWet2PJBPHI&e=" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=243395&view=rev</a><br>
Log:<br>
[X86][SSE] Use bitmasks instead of shuffles where possible.<br>
<br>
VPAND is a lot faster than VPSHUFB and VPBLENDVB - this patch ensures we attempt to lower to a basic bitmask before lowering to the slower byte shuffle/blend instructions.<br>
<br>
Split off from D11518.<br>
<br>
Differential Revision: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11541&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=ouU319mGCM_P2i5-yLUsQY5zONEW0SFpxh6K3mi8opc&s=qP-DwlvvcH3KZHOQRIICOXWT3VocNHeWQ1PU9hxqfxk&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11541</a><br>
<br>
Modified:<br>
llvm/trunk/lib/Target/X86/X86ISelLowering.cpp<br>
llvm/trunk/test/CodeGen/X86/vector-shuffle-128-v16.ll<br>
llvm/trunk/test/CodeGen/X86/vector-shuffle-256-v32.ll<br>
llvm/trunk/test/CodeGen/X86/vector-zext.ll<br>
<br></div>
<snip> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Modified: llvm/trunk/test/CodeGen/X86/vector-shuffle-256-v32.ll<br>
URL: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_llvm_trunk_test_CodeGen_X86_vector-2Dshuffle-2D256-2Dv32.ll-3Frev-3D243395-26r1-3D243394-26r2-3D243395-26view-3Ddiff&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=ouU319mGCM_P2i5-yLUsQY5zONEW0SFpxh6K3mi8opc&s=pL9Zp6z_qFKE54rohTftCjAI_uF-ICEZEGkpZfmBp5I&e=" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/vector-shuffle-256-v32.ll?rev=243395&r1=243394&r2=243395&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/test/CodeGen/X86/vector-shuffle-256-v32.ll (original)<br>
+++ llvm/trunk/test/CodeGen/X86/vector-shuffle-256-v32.ll Tue Jul 28 03:54:41 2015<br>
@@ -951,17 +951,15 @@ define <32 x i8> @shuffle_v32i8_zz_01_zz<br>
; AVX1-LABEL: shuffle_v32i8_zz_01_zz_03_zz_05_zz_07_zz_09_zz_11_zz_13_zz_15_zz_17_zz_19_zz_21_zz_23_zz_25_zz_27_zz_29_zz_31:<br>
; AVX1: # BB#0:<br>
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1<br>
-; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [128,1,128,3,128,5,128,7,128,9,128,11,128,13,128,15]<br>
-; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1<br>
-; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0<br>
+; AVX1-NEXT: vmovaps {{.*#+}} xmm2 = [0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255]<br>
+; AVX1-NEXT: vandps %xmm2, %xmm1, %xmm1<br>
+; AVX1-NEXT: vandps %xmm2, %xmm0, %xmm0<br>
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0<br>
; AVX1-NEXT: retq<br>
;<br></div></blockquote><div><br>In this test, we end up with a long sequence of
instructions (on AVX1) because the 32Byte shuffle is expanded into
two 16Byte shuffles plus an insert_subvector (which eventually becomes a
vinsertf128). However, on AVX1, extract/insert subvector nodes from/to
32byte vectors can only be expanded to vextractf128/vinsertf128 instructions. So (if
my understanding is correct) there is no way (on AVX1) to keep
the computation in the integer domain.<br><br> Ideally, on AVX1 we should have a single 'vandps' (similarly to what we currently do for AVX2) instead of a 'vmovaps+vextractf+vandps+vandps+vinsertf'. What do you think?<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
; AVX2-LABEL: shuffle_v32i8_zz_01_zz_03_zz_05_zz_07_zz_09_zz_11_zz_13_zz_15_zz_17_zz_19_zz_21_zz_23_zz_25_zz_27_zz_29_zz_31:<br>
; AVX2: # BB#0:<br>
-; AVX2-NEXT: vmovdqa {{.*#+}} ymm1 = [255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0,255,0]<br>
-; AVX2-NEXT: vpxor %ymm2, %ymm2, %ymm2<br>
-; AVX2-NEXT: vpblendvb %ymm1, %ymm2, %ymm0, %ymm0<br>
+; AVX2-NEXT: vandps {{.*}}(%rip), %ymm0, %ymm0<br>
; AVX2-NEXT: retq<br>
%shuffle = shufflevector <32 x i8> %a, <32 x i8> zeroinitializer, <32 x i32> <i32 32, i32 1, i32 34, i32 3, i32 36, i32 5, i32 38, i32 7, i32 40, i32 9, i32 42, i32 11, i32 44, i32 13, i32 46, i32 15, i32 48, i32 17, i32 50, i32 19, i32 52, i32 21, i32 54, i32 23, i32 56, i32 25, i32 58, i32 27, i32 60, i32 29, i32 62, i32 31><br>
ret <32 x i8> %shuffle<br>
<br></div></blockquote><div><br></div></div></div></div></div>