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

[Hal Finkel]

----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Monday, October 29, 2012 12:33:11 PM
> Subject: Re: [llvm-commits] [RFC/PATCH] PPCDoubleDouble compile-time arithmetic
> 
> Hi Hal,
> 
> On 29/10/12 18:26, Hal Finkel wrote:
> > ----- Original Message -----
> >> From: "Duncan Sands" <baldrick at free.fr>
> >> To: llvm-commits at cs.uiuc.edu
> >> Sent: Monday, October 29, 2012 12:04:33 PM
> >> Subject: Re: [llvm-commits] [RFC/PATCH] PPCDoubleDouble
> >> compile-time	arithmetic
> >>
> >> Hi Ulrich,
> >>
> >> On 29/10/12 17:11, Ulrich Weigand wrote:
> >>> Chris Lattner <clattner at apple.com> wrote on 28.10.2012 05:03:31:
> >>>
> >>>> 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.
> >>>
> >>> First of all, I'd tend to agree with Hal and Bill that expanding
> >>> PowerPC double-double in the front end might be an interesting
> >>> optimization for the longer term, but this is really an
> >>> independent
> >>> issue of what I'm addressing with the current patch set.  As you
> >>> note as well, we'd still need APFloat support for things like
> >>> constant parsing ...
> >>
> >> it could be build on top of APFloat instead of being part of
> >> APFloat.
> >>
> >>> So I'd certainly propose we should commit something along the
> >>> lines
> >>> of my patch soon, since without this long double is pretty much
> >>> unusable.  Anything further can then still be done later on.  Do
> >>> you agree, or would you object to the patch at this stage?
> >>>
> >>>
> >>> Now, thinking further about what we could do in the future: it
> >>> seems to me that to really "simplify the IR" would mean to
> >>> completely remove "ppc_fp128" as a primitive type on the IR
> >>> level.
> >>
> >> I'm pretty sure this is what Chris has in mind (based on previous
> >> discussions).
> >
> > Yes, this is also my understanding.
> >
> > Nevertheless, I think that, regardless of the later direction, this
> > is the correct incremental step. It does, after all, make APFloat
> > cleaner, removing a bunch of non-working code and replacing it
> > with (simpler) working code. Unless someone has a specific
> > objection, let's commit this.
> 
> I don't have any objection to it as an incremental step.

Okay, thanks! Given that Chris also did not object to this as an incremental step, Ulrich, please commit.

 -Hal

> 
> Ciao, Duncan.
> 
> 

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