On September 15, 2016 5:52:34 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >On 09/14/2016 02:24 AM, Richard Biener wrote: >> On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law <l...@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
