[llvm-commits] CVS: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp LegalizeDAG.cpp SelectionDAG.cpp SelectionDAGISel.cpp TargetLowering.cpp

Chris Lattner clattner at apple.com
Wed Jun 27 10:12:44 PDT 2007


On Jun 27, 2007, at 7:59 AM, Dan Gohman wrote:

>>> Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
>>> diff -u llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.409 llvm/
>>> lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.410
>>> --- llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.409	Fri Jun 22
>>> 09:59:07 2007
>>> +++ llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp	Mon Jun 25
>>> 11:23:39 2007
>>> @@ -673,7 +673,9 @@
>>>  SDOperand SelectionDAG::getConstantFP(double Val, MVT::ValueType  
>>> VT,
>>>                                        bool isTarget) {
>>>    assert(MVT::isFloatingPoint(VT) && "Cannot create integer FP
>>> constant!");
>>> -  if (VT == MVT::f32)
>>> +  MVT::ValueType EltVT =
>>> +    MVT::isVector(VT) ? MVT::getVectorElementType(VT) : VT;
>>
>> I don't understand this change.  getConstantFP shouldn't be called on
>> vectors, should it?  This seems to be a strange thing to overload.
>
> Oops; that's a small part of an unrelated set of changes I'm working
> on. That code isn't used currently.
>
> Just as there isn't a special ADD node kind for vectors -- just an ADD
> kind with nodes that can have a vector ValueType, ConstantFP can also
> be "vectorized". A ConstantFP with a vector ValueType is a vector  
> constant,
> equivalent to what is currently represented as a splat BUILD_VECTOR,
> except that it's easier to work with :).

I'm not opposed to doing this, but I don't think we should overload  
ConstantFP() and getConstantFP() for this.  Could you make a new  
VectorConstantFP or something?

-Chris



More information about the llvm-commits mailing list