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

[Chris Lattner]

On Oct 29, 2012, at 3:35 PM, Alex Rosenberg <alexr at leftfield.org> wrote:

> On Oct 27, 2012, at 9:03 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 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.
> 
> Won't splitting the operations pessimize all the IR-level transforms that would apply to the logical operation?

This is extremely unlikely.  The PPC DoubleDouble type doesn't obey IEEE semantics, so virtually any of these operations that the optimizer is already doing are incorrect.  We previously avoided trivial things like constant folding because the IEEE semantics are not correct for DoubleDouble (this just got removed, making us *less correct*).

> Wouldn't the split operations prevent some reordering transforms due to the difference in FP exceptions between the logical ops and the actual sub-ops?

LLVM doesn't model FP exceptions.  If we start doing this, splitting doubledouble ops into independent suboperations will actually help model the exception behavior more correctly.

The *only* two disadvantages there are of splitting them that I know of are:

1) All front ends that support it would have to do the expansion, arguing for an IRBuilder-like interface to do this.
2) The libcalls that are generated will need to be marked as readnone, but there may also be some instcombine-like simplifications that apply well to them.

The current implementation wasn't done with performance in mind, only the desire for functional correctness.  It isn't particularly awesome in any dimension, splitting each value into two doubles would be clearly better.

-Chris