[LLVMdev] Suggested change to docs re: double/float constant syntax.
John Clements
aoeullvm at brinckerhoff.org
Tue Feb 10 22:28:06 PST 2009
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
More information about the llvm-dev
mailing list