[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

[Chris Lattner]

On Sep 16, 2007, at 9:55 AM, Dale Johannesen wrote:
> On Sep 14, 2007, at 11:12 PM, Chris Lattner wrote:
>>> +ConstantFP *ConstantFP::getNegativeZero(const Type *Ty) {
>>> +  APFloat apf = cast <ConstantFP>(Constant::getNullValue(Ty))-
>>>> getValueAPF();
>>> +  apf.changeSign();
>>> +  return ConstantFP::get(Ty, apf);
>>> +}
>>
>> This seems fairly expensive.  Why not just start by creating an
>> APFloat of the appropriate zero type, changing its sign, then
>> returning it.  Why start with a Constant?
>
> Because there's no easy way to make "an APFloat of the appropriate
> zero type", you need a switch like the one in getNullValue.  This is
> cleaner.  (It's true I'm getting tired of converting from MVT to Type
> to fpSemantics all over the place, maybe I'll do something about
> that...)

Ah, good point.  I think that's a great problem to solve :).  One  
possibility: how about making APFloat use an MVT as its "fpsemantics"  
enum?

-Chris