[llvm-commits] [RFC/PATCH] PPCDoubleDouble compile-time arithmetic

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Fri Oct 26 06:27:42 PDT 2012


Hello,

on PowerPC, there is no true "long double" data type supported by hardware.
The PowerPC ABI instead defines "long double" to be a 128-bit type
interpreted as a pair of doubles.  The LLVM back-end seems to support code
generation involving this data type well enough.  However, the clang
front-end currenly has only extremely limited support for this type; in
particular, it is unable to parse long double floating-point constants.

The reason for this is that while the APFloat data type provides
PPCDoubleDouble floating-point semantics, it disallows any compile-time
arithmetic on such numbers.  One way to implement this would be to fully
emulate the operations done by run-time arithmetic routines on double
pairs.  However, this is a significant effort to ensure equivalent results,
and would also require restructuring of the APFloat data type and
operations.

On the other hand, GCC doesn't implement long double compile-time
arithmetic on PowerPC this way either.  Instead, GCC's real.c simply
pretends the type is a 106-bit IEEE floating-point type, and implements all
operations using its regular IEEE arithmetic routines, parametrized to the
corresponding "pretend" mantissa and exponent sizes.   This has the effect
that not all operations give the identical result as run-time operations on
double-double pairs would, but it is good enough for the most common use
cases (where "long double" is in fact used as if it were and IEEE type with
larger mantissa).  In particular, it's good enough to parse floating-point
constants ...

It turns out that it is quite straightforward to implement long double
artithmetic along those same lines in LLVM's APFloat.   The patch below
implements a representation that is exactly equivalent to GCC's real.c
representation of long double on PowerPC.   This fixes a large number of
test suite failures (no test fails due to long double issues any more):
Clang :: ARCMT/objcmt-numeric-literals.m
Clang :: CXX/expr/p9.cpp
Clang :: CXX/lex/lex.literal/lex.ext/p4.cpp
Clang :: CXX/lex/lex.literal/lex.ext/p7.cpp
Clang :: CodeGen/2008-01-21-PackedStructField.c
Clang :: CodeGen/builtins.c
Clang :: CodeGen/global-with-initialiser.c
Clang :: Sema/builtin-unary-fp.c
Clang :: Sema/constant-builtins-2.c
Clang :: Sema/constant-builtins.c
Clang :: SemaCXX/cxx11-ast-print.cpp
Clang :: SemaObjC/objc-literal-nsnumber.m
Clang-Unit :: AST/Release
+Asserts/ASTTests/StmtPrinter.TestFloatingPointLiteral
MultiSource/Applications/sqlite3/sqlite3
MultiSource/Benchmarks/McCat/08-main/main
MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive-basicmath
MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4  (*)
SingleSource/Benchmarks/CoyoteBench/fftbench
SingleSource/Benchmarks/Misc-C++-EH/spirit
SingleSource/Benchmarks/Misc-C++/Large/ray
SingleSource/Benchmarks/Misc/mandel
SingleSource/UnitTests/2009-04-16-BitfieldInitialization
SingleSource/UnitTests/byval-alignment

(*) additionally requires two other patches to fix unrelated problems


The first patch appended below implements the core arithmetic routines to
treat PPCDoubleDouble as 106-bit mantissa type, including a couple of unit
tests verifying basic behaviour.  Two follow-on patches clean up APFloat
code further: the first by removing the now unused "sign2" and "exponent2"
bit fields, and the second by removing the now unused "arithmeticOK" logic.
A final fourth patch removes a number of special-case checks for
PPCDoubleDouble in the LLVM back-end, where the code used to explicitly
avoid performing compile-time arithmetic on such numbers since it wasn't
implemented.

Note that this fourth patch also includes a tweak to a test case; that test
explicitly verified that converting a constant integer 0 to PowerPC long
double invokes a run-time library call.  Since this is now actually done at
compile-time, that routine is no longer used in that test.


Would this be OK to commit?

Bye,
Ulrich

(See attached file: diff-llvm-ppcdoubledouble)
(See attached file: diff-llvm-ppcdoubledouble-cleanup)
(See attached file: diff-llvm-ppcdoubledouble-arithmeticok)
(See attached file: diff-llvm-ppcdoubledouble-enable)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-ppcdoubledouble
Type: application/octet-stream
Size: 9022 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121026/637c8a07/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-ppcdoubledouble-cleanup
Type: application/octet-stream
Size: 4080 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121026/637c8a07/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-ppcdoubledouble-arithmeticok
Type: application/octet-stream
Size: 7118 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121026/637c8a07/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-llvm-ppcdoubledouble-enable
Type: application/octet-stream
Size: 14292 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121026/637c8a07/attachment-0003.obj>


More information about the llvm-commits mailing list