[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