[llvm-commits] [llvm] r73431 - in /llvm/trunk: include/llvm/ include/llvm/Analysis/ lib/Analysis/ lib/Transforms/Instrumentation/ lib/Transforms/Scalar/ lib/VMCore/ test/Feature/ test/Transforms/InstCombine/

[Dan Gohman]

On Jun 15, 2009, at 4:57 PM, Chris Lattner wrote:


>
> On Jun 15, 2009, at 4:33 PM, Dan Gohman wrote:
>
>
>>> Hi Dan,
>>>
>>>
>>>
>>> Why should ConstantInt/FP::get allow a vector operand?  It seems  
>>> very
>>>
>>> strange to me to allow this.
>>>
>>
>>
>> It's a convenience for code that handles both vector and scalar
>>
>> values. In the same sense that the vector form of an add is an
>>
>> add that applies to each element of a vector, the vector form
>>
>> of a constant is a constant vector with each element equal to
>>
>> the constant.
>>
>
> The part that confuses me is that code should generally know when it
> is working on a vector or not.  Is ConstantInt::get(4, <vector>)
> better than ConstantVector::get(4, <vector>) ?

There are lots of places where vector/scalar-independent code
is useful. As one example, the instcombine code that converts

   %b = trunc i64 %a to i32
   %c = zext i32 %b to i64
to
   %c = and i64, 4294967295

now performs the same optimization for vectors, as a result
of this commit.

>
>
>
>>> In general, please split up logically distinct changes into  
>>> different
>>>
>>> pieces, it would be nice to have the core IR changes separately from
>>>
>>> the SCEV changes,
>>>
>>
>>
>> The SCEV changes here were needed in order to conform to
>>
>> the core IR API changes.
>>
>
> Ok, but couldn't the API changes go in first?

Not without breaking the build. I probably could have
split the new convenience function out into a separate
patch, but that would have made the SCEV changes in the
original patch more verbose.

Dan