[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/

Chris Lattner clattner at apple.com
Tue Sep 11 14:36:24 PDT 2007


> Add APInt interfaces to APFloat (allows directly
> access to bits).  Use them in place of float and
> double interfaces where appropriate.
> First bits of x86 long double constants handling
> (untested, probably does not work).

Nice!

> ====================================================================== 
> ========
> --- 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?

> +/// 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.

-Chris



More information about the llvm-commits mailing list