[PATCH] D52548: Stop instcombining propagating wider shufflevector arguments to predecessors.

[Sanjay Patel via llvm-commits]

The backend bug may be masked after

https://reviews.llvm.org/rL343406

On Sat, Sep 29, 2018 at 8:24 AM Sanjay Patel <spatel at rotateright.com> wrote:

>
>
> On Sat, Sep 29, 2018 at 7:52 AM Jan Vesely <jan.vesely at rutgers.edu> wrote:
>
>>
>> it creates <3 x i8>, which is then shuffled into another <3 x i8>, which
>> is then bitcast to <4 x i8>:
>>
>>   %vecinit.i = insertelement <3 x i8> undef, i8 %2, i32 0
>>   %vecinit1.i = insertelement <3 x i8> %vecinit.i, i8 %3, i32 1
>>   %vecinit4.i = insertelement <3 x i8> %vecinit1.i, i8 %4, i32 2
>>
>>   %extractVec = shufflevector <3 x i8> %vecinit4.i, <3 x i8> undef, <4 x
>> i32> <i32 0, i32 1, i32 2, i32 undef>
>>   ^^^ the shuffle result should probably be <4 x i8> ????
>>
>
> Thanks for reporting the bug. The result of that shuffle is <4 x i8>; the
> mask has 4 elements:
> http://llvm.org/docs/LangRef.html#shufflevector-instruction
>
> So I think we've exposed a backend bug. Can you file a bug report and
> attach the test files there? Given that this patch fixes a miscompile in
> IR, I'd rather not revert it unless we can't correct the backend in some
> reasonable amount of time.
>
> The test case also suggests that we can limit the fix that this patch
> imposed: if we're shuffling only to extend a series of insertelement ops,
> then that's a good candidate for widening because we are not introducing
> any wider math ops. That's a workaround for the backend bug in this
> particular case, but it doesn't solve the root cause of the crashing.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180930/2c7f50bd/attachment.html>