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

[Duncan Sands]

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.

Ciao, Duncan.