John Clements
2009-Feb-11 06:28 UTC
[LLVMdev] Suggested change to docs re: double/float constant syntax.
It appears to me based on my experiments with llvm-as that literal floating-point constants may be specified in the 64-bit IEEE hexadecimal format, but not in the 32-bit format. For instance, this file: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "i386-apple-darwin9.5" @mydouble = constant double 0x432ff973cafa8000 @myfloat = constant float 0x405b126f signals this error: uccello:/tmp clements$ llvm-as foo2.s llvm-as: foo2.s:6:27: floating point constant invalid for type @myfloat = constant float 0x405b126f ^ If I'm correct in this assumption, I suggest mentioning this in the language reference. In the interest of not making work for other people, I'll suggest a drop-in replacement. Here's what's currently there: The one non-intuitive notation for constants is the optional hexadecimal form of floating point constants. For example, the form 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double 4.5e+15'. The only time hexadecimal floating point constants are required (and the only time that they are generated by the disassembler) is when a floating point constant must be emitted but it cannot be represented as a decimal floating point number. For example, NaN's, infinities, and other special values are represented in their IEEE hexadecimal format so that assembly and disassembly do not cause any bits to change in the constants. I would instead write this: Floating-point constants may also be specified using the 64-bit IEEE hexadecimal format. For example, the decimal floating-point form 'double 4.5e+15' may also be written as 'double 0x432ff973cafa8000'. Certain floating-values (NaNs, infinities, and other special values) may only be textually represented in the hexadecimal format. The disassembler will use the more decimal floating-point form whenever possible. All the best, John Clements
Dale Johannesen
2009-Feb-11 21:37 UTC
[LLVMdev] Suggested change to docs re: double/float constant syntax.
On Feb 10, 2009, at 10:28 PMPST, John Clements wrote:> It appears to me based on my experiments with llvm-as that literal > floating-point constants may be specified in the 64-bit IEEE > hexadecimal format, but not in the 32-bit format. For instance, this > file: > > target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- > i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- > f80:128:128" > target triple = "i386-apple-darwin9.5" > > @mydouble = constant double 0x432ff973cafa8000 > @myfloat = constant float 0x405b126fCorrect; constants of type float can be specified, but use the double format. Their values must actually fit in a float with no loss of information (i.e. (double)(float)doublevalue bitwise== doublevalue), which is checked by the reader.> signals this error: > > uccello:/tmp clements$ llvm-as foo2.s > llvm-as: foo2.s:6:27: floating point constant invalid for type > @myfloat = constant float 0x405b126f > ^ > > If I'm correct in this assumption, I suggest mentioning this in the > language reference. In the interest of not making work for other > people, I'll suggest a drop-in replacement. > > Here's what's currently there: > > The one non-intuitive notation for constants is the optional > hexadecimal form of floating point constants. For example, the form > 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) > 'double 4.5e+15'. The only time hexadecimal floating point constants > are required (and the only time that they are generated by the > disassembler) is when a floating point constant must be emitted but it > cannot be represented as a decimal floating point number. For > example, > NaN's, infinities, and other special values are represented in their > IEEE hexadecimal format so that assembly and disassembly do not cause > any bits to change in the constants.This is somewhat inaccurate anyway; all non-special binary FP constants can be represented exactly as decimal FP (though the reverse is not true), but the representation can be thousands of digits long. The hex form is used in such cases. There's also long double constants that aren't documented. I'll fix it, thanks.> I would instead write this: > > Floating-point constants may also be specified using the 64-bit IEEE > hexadecimal format. For example, the decimal floating-point form > 'double 4.5e+15' may also be written as 'double 0x432ff973cafa8000'. > Certain floating-values (NaNs, infinities, and other special values) > may only be textually represented in the hexadecimal format. The > disassembler will use the more decimal floating-point form whenever > possible. > > > All the best, > > John Clements > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Maybe Matching Threads
- [LLVMdev] Floating point constants (bug?)
- [LLVMdev] a constant folding case causing different results w/ot optimization
- [LLVMdev] how to convert from float to int with round to even
- [LLVMdev] Buggy assertion in APFloat::convertFromHexadecimalString
- [LLVMdev] Generating Floating point constants