[PATCH][CodeGen] Fix a bug in bitcast optimization of DAGCombiner
james at jamesmolloy.co.uk
Tue Mar 31 03:43:13 PDT 2015
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 .
> 2015-03-31 17:47 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>:
>> The small patch attached is to fix a bug in bitcast optimization of
>> 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
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits