[llvm-commits] [llvm] r41967 - in /llvm/trunk: include/llvm/ADT/APInt.h include/llvm/ADT/FoldingSet.h include/llvm/Constants.h lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp lib/Support/APInt.cpp lib/Support/FoldingSet.cpp lib/Target/CBackend/CBackend.cpp lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86RegisterInfo.cpp lib/Transforms/Scalar/InstructionCombining.cpp lib/VMCore/Constants.cpp

[Evan Cheng]

Sent from my iPhone

On Sep 15, 2007, at 12:16 AM, Dale Johannesen <dalej at apple.com> wrote:

>
> On Sep 14, 2007, at 11:12 PM, Chris Lattner wrote:
>>> @@ -4722,9 +4737,11 @@
>>>     if (DestVT == MVT::f64) {
>>>       // do nothing
>>>       Result = Sub;
>>> -    } else {
>>> +    } else if (DestVT == MVT::f32) {
>>>      // if f32 then cast to f32
>>>       Result = DAG.getNode(ISD::FP_ROUND, MVT::f32, Sub);
>>> +    } else if (DestVT == MVT::f80) {
>>> +      Result = DAG.getNode(ISD::FP_EXTEND, MVT::f80, Sub);
>>>     }
>>
>> How about "if DestVT < f32 use round.  If DestVT > f64, use
>> FP_EXTEND"?
>
> Comparisons other than equality against an enum?  Ick.  IMO, that
> sort of thing
> is a bad misuse of enums.  Obviously you disagree, we should talk?
>
>>> ===
>>> ==================================================================
>>> =
>>> ========
>>> --- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp (original)
>>> +++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Fri Sep 14
>>> 17:26:36 2007
>>> @@ -3724,9 +3714,15 @@
>>>   if (const ConstantSDNode *CSDN = dyn_cast<ConstantSDNode>(this)) {
>>>     cerr << "<" << CSDN->getValue() << ">";
>>>   } else if (const ConstantFPSDNode *CSDN =
>>> dyn_cast<ConstantFPSDNode>(this)) {
>>> -    cerr << "<" << (&CSDN->getValueAPF().getSemantics()
>>> ==&APFloat::IEEEsingle ?
>>> -                    CSDN->getValueAPF().convertToFloat() :
>>> -                    CSDN->getValueAPF().convertToDouble()) << ">";
>>> +    if (&CSDN->getValueAPF().getSemantics()==&APFloat::IEEEsingle)
>>> +      cerr << "<" << CSDN->getValueAPF().convertToFloat() << ">";
>>> +    else if (&CSDN->getValueAPF().getSemantics()
>>> ==&APFloat::IEEEdouble)
>>> +      cerr << "<" << CSDN->getValueAPF().convertToDouble() << ">";
>>> +    else {
>>> +      cerr << "<APFloat(";
>>> +      CSDN->getValueAPF().convertToAPInt().dump();
>>> +      cerr << ")>";
>>> +    }
>>
>> APFloat really needs a "convertToString" method. :)
>
> Yeah.  That would help CBackend too.  It's not trivial.
>
>>> ===
>>> ==================================================================
>>> =
>>> ========
>>> --- llvm/trunk/lib/Target/X86/X86RegisterInfo.cpp (original)
>>> +++ llvm/trunk/lib/Target/X86/X86RegisterInfo.cpp Fri Sep 14
>>> 17:26:36 2007
>>> @@ -168,7 +168,11 @@
>>>     Opc = X86::MOV32_mr;
>>>   } else if (RC == &X86::GR16_RegClass) {
>>>     Opc = X86::MOV16_mr;
>>> +  } else if (RC == &X86::RFP80RegClass) {
>>> +    Opc = X86::ST_FpP80m;   // pops
>>>   } else if (RC == &X86::RFP64RegClass || RC == &X86::RSTRegClass) {
>>> +    /// FIXME spilling long double values as 64 bit does not work.
>>> +    /// We need RST80, unfortunately.
>>
>> The FP Stack has 80 bit load and store instructions, what is the
>> issue? or is it just a todo?
>
> I may be missing something, but I think  when we've gotten to the RST
> regclass,
> we don't know what size the value in the register is, so we'd need to

Right.

>
> use the 80-bit
> insns for all spills.  That's possible, but slower and more
> consumptive of stack space.

I agree we don't want to hurt performance of 64 bit to code. So  
defaulting to 80 bit instructions is not ideal. I don't see a solution  
other than creating rst80 register class and duplicating a bunch of  
instructions unfortunately. :(

Evan

>
> I haven't looked recently, but IIRC the time difference is  
> significant.
> (There's a difference in precision of the result also, but that's
> randomly
> optimization-dependent anyway.)
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits