[PATCH][CodeGen] Fix a bug in bitcast optimization of DAGCombiner

[James Molloy]

Hi Jiangning,

I don't understand your logic here - the upper lanes can be undef, right.
But undef is a contract that means "anything". So if we zero-extend, we
make the upper lanes zero, but zero is a valid implementation of undef.

Cheers,

James

On Tue, 31 Mar 2015 at 10:53 Jiangning Liu <liujiangning1 at gmail.com> wrote:

> BTW, this patch is to fix https://llvm.org/bugs/show_bug.cgi?id=23065 .
>
> Thanks,
> -Jiangning
>
> 2015-03-31 17:47 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>:
>
>> Hi,
>>
>> The small patch attached is to fix a bug in bitcast optimization of
>> DAGCombiner.
>>
>> Originally, the code tries to optimize bitcast with build_vector input to
>> be a scalar_to_vector, if only the bitcast and build_vector can meet some
>> conditions. In particular, it thought "ThisVal.zext(SrcBitSize) == OpVal"
>> is one of the requirements. This requirement means, if zero extension of a
>> narrow element value is equal to the original wide element value, the
>> optimization would be allowed. Unfortunately this is incorrect, because the
>> semantic of scalar_to_vector is the top 1 to N-1 elements are undef rather
>> than zero. So no matter we use zero_extension or sign_extension, this
>> transformation would be always invalid. The patch attached disables this
>> optimization.
>>
>> Thanks,
>> -Jiangning
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150331/210e6e68/attachment.html>