[llvm-commits] [llvm] r41858 - in /llvm/trunk: include/llvm/ADT/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Support/ lib/Target/CBackend/ lib/Target/MSIL/ lib/Target/X86/ lib/VMCore/ tools/llvm2cpp/

[Dale Johannesen]

On Sep 11, 2007, at 2:36 PM, Chris Lattner wrote:
>> ===================================================================== 
>> =
>> ========
>> --- llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp (original)
>> +++ llvm/trunk/lib/Bitcode/Writer/BitcodeWriter.cpp Tue Sep 11
>> 13:32:33 2007
>> @@ -527,13 +527,20 @@
>>        Code = bitc::CST_CODE_FLOAT;
>>        const Type *Ty = CFP->getType();
>>        if (Ty == Type::FloatTy)
>> -        Record.push_back(FloatToBits(CFP->getValueAPF
>> ().convertToFloat()));
>> +        Record.push_back((uint32_t)*CFP->getValueAPF
>> ().convertToAPInt().
>> +                                      getRawData());
>>        else if (Ty == Type::DoubleTy) {
>> +        Record.push_back(*CFP->getValueAPF().convertToAPInt
>> ().getRawData());
>
> In cases where you know you're dealing with a float or a double, it
> would be better to use:
>          CFP->getValueAPF().convertToAPInt().getZExtValue();
>
> instead of getRawData().  In general, it is best to minimize use of
> getRawData(), because if APInt ever changes, we will have to touch
> each of them.  In this specific case, it also allows you to merge the
> float/double cases together.
>
> There are a bunch of examples of this in the patch.  I know it's a
> pain, but can you please switch them?

OK.  I consider using the same interface everywhere to be a  good idea,
but not as good an idea as sharing the float & double cases.

>> +/// Treat api as containing the bits of a floating point number.
>> Currently
>> +/// we infer the floating point type from the size of the APInt.
>> FIXME: This
>> +/// breaks when we get to PPC128 and IEEE128 (but both cannot
>> exist in the
>> +/// same compile...)
>
> They can't both exist in the same module, but this method won't know
> which it is getting without some context passed in.

Or globally visible, or calling a target hook.  Yeah, I know.  I  
considered
having the APInt's be 128 bits always and passing the type in parallel,
but that leads to much uglier (& less efficient) code....I suppose we  
could
allocate an extra bit for one of them.  Ugh.