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

[Chris Lattner]

Hi Ulrich,

Given that the PowerPC format expands out into operations on two doubles, how reasonable would it be for clang to generate pre-expanded IR that exposed this lowering to the optimizers?

This wouldn't help you with constant parsing, but would simplify the IR and optimizer and almost certainly give you better code quality for this type.

-Chris

On Oct 26, 2012, at 3:27 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> 
> 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)
> <diff-llvm-ppcdoubledouble>
> <diff-llvm-ppcdoubledouble-cleanup>
> <diff-llvm-ppcdoubledouble-arithmeticok>
> <diff-llvm-ppcdoubledouble-enable>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits