[PATCH][AVX512] Fix miscompile for unpack

Adam Nemet anemet at apple.com
Tue Sep 2 10:55:10 PDT 2014


Ping?

On Aug 13, 2014, at 11:48 PM, Adam Nemet <anemet at apple.com> wrote:

> Hi Elena,
> 
> r189189 implemented AVX512 unpack by essentially performing a 256-bit unpack
> between the low and the high 256 bits of src1 into the low part of the
> destination and another unpack of the low and high 256 bits of src2 into the
> high part of the destination.
> 
> I don't think that's how unpack works.  AVX512 unpack simply has more 128-bit
> lanes but other than it works the same way as AVX.  So in each 128-bit lane, we're
> always interleaving certain parts of both operands rather different parts of
> one of the operands.
> 
> E.g. for this:
> __v16sf a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };
> __v16sf b = { 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
> __v16sf c = __builtin_shufflevector(a, b, 0, 8, 1, 9, 4, 12, 5, 13, 16,
>                                             24, 17, 25, 20, 28, 21, 29);
> 
> we generated punpcklps (notice how the elements of a and b are not interleaved
> in the shuffle).  In turn, c was set to this:
> 
>  0 16 1 17 4 20 5 21 8 24 9 25 12 28 13 29
> 
> Obviously this should have just returned the mask vector of the shuffle
> vector.
> 
> I mostly reverted this change and made sure the original AVX code worked
> for 512-bit vectors as well.
> 
> Also updated the tests because they matched the logic from the code.
> 
> Please let me know if this looks good.
> 
> Thanks,
> Adam
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AVX512-Fix-miscompile-for-unpack.patch
Type: application/octet-stream
Size: 7925 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140902/db3e2f21/attachment.obj>
-------------- next part --------------



More information about the llvm-commits mailing list