[PATCH] D18850: [X86]: Fix for PR27251

[Smith, Kevin B via llvm-commits]

>-----Original Message-----
>From: Simon Pilgrim [mailto:llvm-dev at redking.me.uk]
>Sent: Thursday, April 07, 2016 11:03 AM
>To: Smith, Kevin B <kevin.b.smith at intel.com>; Kreitzer, David L
><david.l.kreitzer at intel.com>; ahmed.bougacha at gmail.com
>Cc: llvm-dev at redking.me.uk; llvm-commits at lists.llvm.org
>Subject: Re: [PATCH] D18850: [X86]: Fix for PR27251
>
>RKSimon added a subscriber: RKSimon.
>RKSimon added a comment.
>
>> >
>
>>
>
>> >
>
>>
>
>> >
>
>>
>
>> > Comment at: test/CodeGen/X86/vector-blend.ll:1011
>
>>
>
>> > @@ -1010,3 +1010,3 @@
>
>>
>
>> >  ; SSE2-NEXT:    pslld $31, %xmm1
>
>>
>
>> >  ; SSE2-NEXT:    psrad $31, %xmm1
>
>>
>
>> >
>
>>
>
>> > ; SSE2-NEXT:    pxor %xmm1, %xmm0
>
>>
>
>> > ---------------------------------
>
>>
>
>> >
>
>>
>
>> > I know this isn't related to your change, but the redundant shifts here are
>
>>
>
>> > pretty gross.
>
>>
>
>>
>
>> Why are the shifts redundant?  One is a shift left by 31, and the other is a
>arithmetic shift right by 31.
>
>>  This has the effect of propagating bit 0 through all 32 bits of the vector
>element.
>
>
>For the pre-SSE41 cases its doing ashr( shl( lshr( v, 31 ), 31 ), 31) which
>should be combined to ashr( v, 31 ) - this isn't that difficult.
>
>For the SSE41 cases we don't need the shifts at all as (v)blendvps will select
>elements based on the sign bit alone, but the vselect/blendv relationship is
>rather nasty (change in input type behaviour after legalization) and I can
>imagine a number of problems getting it to work cleanly - I've hit some of
>these before trying to do late constant folding of vselect.

Thanks for further clarifying that.  I had missed (because it wasn't in Dave's email, only in the test itself)
that the sequence started out with a psrld $31, %xmm1.

As Dave noted, that wasn't what this change-set was about, but the test simply happened to
show that redundancy.

>
>
>Repository:
>  rL LLVM
>
>http://reviews.llvm.org/D18850
>
>