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

Sat Oct 27 21:51:22 PDT 2012

I'm not going to stand in the way of this patch if its the right incremental step, but I would really really like to get rid of double double support from LLVM IR.  It just doesn't make any sense to have a type that is always expanded in codegen.  It would also be nice to generate faster and more correct code than gcc!

-Chris

On Oct 27, 2012, at 6:45 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Chris Lattner" <clattner at apple.com>
>> To: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
>> Cc: llvm-commits at cs.uiuc.edu
>> Sent: Saturday, October 27, 2012 11:03:31 PM
>> Subject: Re: [llvm-commits] [RFC/PATCH] PPCDoubleDouble compile-time    arithmetic
>> 
>> 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?
> 
> As I recall, Bill had some thought about how this would interact with the ABI requirements. Bill?
> 
> Chris, I'd like to get this patch in, even if we would like to move some/all support into the frontend. With this patch, we move from something that is 100% broken to something that is 99.9% functional, plus we get a nice cleanup in APFloat. Moving double-double support into clang looks like a major project.
> 
> I do certainly agree, however, that being able to inline the arithmetic seems like a nice performance win (and it could then be vectorized too).
> 
> Thanks again,
> Hal
> 
>> 
>> 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
>> _______________________________________________
>> 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