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

[Hal Finkel]

Ulrich,

This is great, thanks! A few comments:

+  bool losesInfo;
[and others]

These variable names don't follow the coding conventions. I know that a lot of the old code in APFloat seems to predate the current naming conventions, but we should probably follow them for new code.

Otherwise, these look good to me.

 -Hal

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: llvm-commits at cs.uiuc.edu
> Sent: Friday, October 26, 2012 8:27:42 AM
> Subject: [llvm-commits] [RFC/PATCH] PPCDoubleDouble compile-time arithmetic
> 
> 
> 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)
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory