[llvm] r214628 - [x86] Largely complete the use of PSHUFB in the new vector shuffle

[Chandler Carruth]

On Thu, Aug 14, 2014 at 5:21 AM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> On Thu, Aug 14, 2014 at 4:07 AM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> On Thu, Aug 14, 2014 at 3:45 AM, Patrik Hägglund H <
>> patrik.h.hagglund at ericsson.com> wrote:
>>
>>> Hi Chandler,
>>>
>>> Ping!
>>>
>>
>> Sorry, I got caught up in other bug chasing activities and forgot about
>> this one. I'll try to get to it if you don't sooner....
>>
>>
>>>
>>> I don't know anything about how this code works. Anyhow, I took a quick
>>> look at this. It seems like the call to getTargetShuffleMask (in
>>> combineX86ShufflesRecursively) returns a Mask with 'undef' (-1) values.
>>> However, the code following the call seems to assume that no elements are
>>> 'undef'.
>>>
>>
>> That seems... very, very strange. If it isn't a bug in
>> getTargetShuffleMask (How does it know they are *undef*???) then I think
>> the code following it just needs to be taught to deal with undef masks.
>>
>
> Oh, this isn't undef stuff at all.
>
> X86 target shuffles sometimes will force-zero a lane, and we decode that
> to a '-1' entry in the *target* shuffle mask. Not to be confused with a
> '-1' in the shuffle masks used everywhere else. =/
>
> Anyways, the subsequent code looks *completely and utterly wrong*, both in
> the face of this and other issues. I'll rewrite it shortly.
>

Done and fixed in r215687.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140814/8bd312dd/attachment.html>