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

[Patrik Hägglund H]

Hi Chandler,

> Done and fixed in r215687.

Thanks!

From: chandlerc at google.com [mailto:chandlerc at google.com] On Behalf Of Chandler Carruth
Sent: den 15 augusti 2014 04:53
To: Chandler Carruth
Cc: Patrik Hägglund H; llvm-commits at cs.uiuc.edu
Subject: Re: [llvm] r214628 - [x86] Largely complete the use of PSHUFB in the new vector shuffle


On Thu, Aug 14, 2014 at 5:21 AM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:
On Thu, Aug 14, 2014 at 4:07 AM, Chandler Carruth <chandlerc at gmail.com<mailto:chandlerc at gmail.com>> wrote:
On Thu, Aug 14, 2014 at 3:45 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com<mailto: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/20140815/a1c97a2c/attachment.html>