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

On 13/09/16 12:35, Wilco Dijkstra wrote: > Jakub wrote: >> On Mon, Sep 12, 2016 at 04:19:32PM +, 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

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

On Wed, 21 Sep 2016, Joseph Myers wrote: > On Tue, 20 Sep 2016, Michael Meissner wrote: > > > It would be better to have a fpclassify2 pattern, and if it isn't > > defined, then do the machine independent processing. That is the way it is > > done elsewhere. > > But note: > > * The

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

On Tue, 20 Sep 2016, Jeff Law wrote: > On 09/20/2016 06:00 AM, Tamar Christina wrote: > > > > > > On 16/09/16 20:49, Jeff Law wrote: > > > On 09/12/2016 10:19 AM, Tamar Christina wrote: > > > > Hi All, > > > > + > > > > + /* Re-interpret the float as an unsigned integer type > > > > +

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

On Tue, 20 Sep 2016, Michael Meissner wrote: > It would be better to have a fpclassify2 pattern, and if it isn't > defined, then do the machine independent processing. That is the way it is > done elsewhere. But note: * The __builtin_fpclassify function takes arguments for all the possible

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

On Tue, Sep 20, 2016 at 01:19:07PM +0100, Tamar Christina wrote: > On 19/09/16 23:16, Michael Meissner wrote: > >On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: > >>Hi All, > >> > >>This patch adds an optimized route to the fpclassify builtin > >>for floating point numbers which

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

On Tue, 20 Sep 2016, Jeff Law wrote: > Could we defer lowering in the case where the object is not addressable until > gimple->rtl expansion time? That's the best time to introduce target > dependencies into the code we generate. If we do that (remembering that -fsignaling-nans always wants the

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

On 09/20/2016 06:00 AM, Tamar Christina wrote: On 16/09/16 20:49, Jeff Law wrote: On 09/12/2016 10:19 AM, Tamar Christina wrote: Hi All, + + /* Re-interpret the float as an unsigned integer type + with equal precision. */ + int_arg_type = build_nonstandard_integer_type

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

On 16/09/16 20:49, Jeff Law wrote: On 09/12/2016 10:19 AM, Tamar Christina wrote: Hi All, + + /* Re-interpret the float as an unsigned integer type + with equal precision. */ + int_arg_type = build_nonstandard_integer_type (TYPE_PRECISION (type), 0); + int_arg =

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

On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: > Hi All, > > 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

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

On 09/12/2016 10:19 AM, Tamar Christina wrote: Hi All, 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

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

On September 15, 2016 5:52:34 PM GMT+02:00, Jeff Law wrote: >On 09/14/2016 02:24 AM, Richard Biener wrote: >> On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law wrote: >>> On 09/13/2016 02:41 AM, Jakub Jelinek wrote: On Mon, Sep 12, 2016 at 04:19:32PM +,

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

On 09/14/2016 02:24 AM, Richard Biener wrote: On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law wrote: On 09/13/2016 02:41 AM, Jakub Jelinek wrote: On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: This patch adds an optimized route to the fpclassify builtin for

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

On Thu, 15 Sep 2016, Tamar Christina wrote: > a rather large costs in complexity. Also wouldn't this be problematic > for other functions as well such as expand_builtin_signbit? expand_builtin_signbit computes a word number and the bit position in that word. It has no problem with 128-bit

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

On Thu, 15 Sep 2016, Wilco Dijkstra wrote: > Yes, if there are targets which don't implement TImode operations then > surely they should be automatically split into DImode operations before > or during Expand? The operations generally don't exist if the mode fails the scalar_mode_supported_p

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

Tamar Christina wrote: > On 13/09/16 13:43, Joseph Myers wrote: > > On Tue, 13 Sep 2016, Tamar Christina wrote: >> > >> On 12/09/16 23:33, Joseph Myers wrote: > >>> Why is this boolean false for ieee_quad_format, mips_quad_format and > >>> ieee_half_format?  They should meet your description (even

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

On 13/09/16 13:43, Joseph Myers wrote: On Tue, 13 Sep 2016, Tamar Christina wrote: On 12/09/16 23:33, Joseph Myers wrote: Why is this boolean false for ieee_quad_format, mips_quad_format and ieee_half_format? They should meet your description (even if the x86 / m68k "extended" formats

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

On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law wrote: > On 09/13/2016 02:41 AM, Jakub Jelinek wrote: >> >> On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: >>> >>> This patch adds an optimized route to the fpclassify builtin >>> for floating point numbers which are

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

On 09/13/2016 02:41 AM, Jakub Jelinek wrote: On Mon, Sep 12, 2016 at 04:19:32PM +, 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

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

On Tue, 13 Sep 2016, Wilco Dijkstra wrote: > I would suggest someone with access to a machine with slow FP moves (POWER?) > to benchmark this using the fpclassify test > (glibc/benchtests/bench-math-inlines.c) > so we know for sure. And if for some operations on some architectures the

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

On Tue, 13 Sep 2016, Tamar Christina wrote: > On 12/09/16 23:41, Joseph Myers wrote: > > Are you making endianness assumptions - specifically, does the > > reinterpretation as an integer require that WORDS_BIG_ENDIAN and > > FLOAT_WORDS_BIG_ENDIAN are the same? If so, I think that's OK (in that

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

On Tue, 13 Sep 2016, Tamar Christina wrote: > > > On 12/09/16 23:33, Joseph Myers wrote: > > Why is this boolean false for ieee_quad_format, mips_quad_format and > > ieee_half_format? They should meet your description (even if the x86 / > > m68k "extended" formats don't because of the leading

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

On 12/09/16 23:41, Joseph Myers wrote: Are you making endianness assumptions - specifically, does the reinterpretation as an integer require that WORDS_BIG_ENDIAN and FLOAT_WORDS_BIG_ENDIAN are the same? If so, I think that's OK (in that the only target where they aren't the same seems to be

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

On 12/09/16 23:33, Joseph Myers wrote: Why is this boolean false for ieee_quad_format, mips_quad_format and ieee_half_format? They should meet your description (even if the x86 / m68k "extended" formats don't because of the leading mantissa bit being set for infinities). Ah, I played it a

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

On 12/09/16 23:28, Joseph Myers wrote: On Mon, 12 Sep 2016, Tamar Christina wrote: Similar changes may be useful for __builtin_isfinite, __builtin_isnan, __builtin_isinf, __builtin_isinf_sign, __builtin_isnormal. Will your version always use only integer operations if the format is IEEE

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

Jakub wrote: > On Mon, Sep 12, 2016 at 04:19:32PM +, 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

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

On Mon, Sep 12, 2016 at 04:19:32PM +, 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 >

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

Are you making endianness assumptions - specifically, does the reinterpretation as an integer require that WORDS_BIG_ENDIAN and FLOAT_WORDS_BIG_ENDIAN are the same? If so, I think that's OK (in that the only target where they aren't the same seems to be pdp11 which doesn't use IEEE formats),

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

On Mon, 12 Sep 2016, Tamar Christina wrote: > A limitation with this new approach is that the exponent > of the floating point has to fit in 31 bits and the floating > point has to have an IEEE like format and values for NaN and INF > (e.g. for NaN and INF all bits of the exp must be set). > >

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

On Mon, 12 Sep 2016, Tamar Christina wrote: > Hi All, > > This patch adds an optimized route to the fpclassify builtin > for floating point numbers which are similar to IEEE-754 in format. Similar changes may be useful for __builtin_isfinite, __builtin_isnan, __builtin_isinf,

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

On Mon, Sep 12, 2016 at 6:21 PM, Moritz Klammler wrote: > > Tamar Christina writes: > >> Hi All, >> >> This patch adds an optimized route to the fpclassify builtin >> for floating point numbers which are similar to IEEE-754 in format. >> >> [...] > >

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

Tamar Christina writes: > Hi All, > > This patch adds an optimized route to the fpclassify builtin > for floating point numbers which are similar to IEEE-754 in format. > > [...] I might be the least competent person on this list to review this patch but nevertheless