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

James Molloy james at jamesmolloy.co.uk
Tue Mar 31 03:43:13 PDT 2015

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.



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>

More information about the llvm-commits mailing list