Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

[Richard Biener <rguenther@suse.de>]

On September 15, 2016 5:52:34 PM GMT+02:00, Jeff Law <law@redhat.com> wrote:
>On 09/14/2016 02:24 AM, Richard Biener wrote:
>> On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law <law@redhat.com> wrote:
>>> On 09/13/2016 02:41 AM, Jakub Jelinek wrote:
>>>>
>>>> On Mon, Sep 12, 2016 at 04:19:32PM +0000, Tamar Christina wrote:
>>>>>
>>>>> This patch adds an optimized route to the fpclassify builtin
>>>>> for floating point numbers which are similar to IEEE-754 in
>format.
>>>>>
>>>>> The goal is to make it faster by:
>>>>> 1. Trying to determine the most common case first
>>>>>    (e.g. the float is a Normal number) and then the
>>>>>    rest. The amount of code generated at -O2 are
>>>>>    about the same +/- 1 instruction, but the code
>>>>>    is much better.
>>>>> 2. Using integer operation in the optimized path.
>>>>
>>>>
>>>> Is it generally preferable to use integer operations for this
>instead
>>>> of floating point operations?  I mean various targets have quite
>high
>>>> costs
>>>> of moving data in between the general purpose and floating point
>register
>>>> file, often it has to go through memory etc.
>>>
>>> Bit testing/twiddling is obviously a trade-off for a non-addressable
>object.
>>> I don't think there's any reasonable way to always generate the most
>>> efficient code as it's going to depend on (for example) register
>allocation
>>> behavior.
>>>
>>> So what we're stuck doing is relying on the target costing bits to
>guide
>>> this kind of thing.
>>
>> I think the reason for this patch is to provide a general optimized
>> integer version.
>And just to be clear, that's fine with me.  While there are cases where
>
>bit twiddling hurts, I think bit twiddling is generally better.
>
>
>> I think it asks for a FP (class) propagation pass somewhere (maybe as
>part of
>> complex lowering which already has a similar "coarse" lattice -- not
>that I like
>> its implementation very much) and doing the "lowering" there.
>Not a bad idea -- I wonder how much a coarse tracking of the
>exceptional 
>cases would allow later optimization.

I guess it really depends on the ability to set ffast-math flags on individual stmts (or at least built-in calls).

Richard.

>>
>> Not something that should block this patch though.
>Agreed.
>
>jeff