public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "David Sherwood" <david.sherwood@arm.com>
To: "'Richard Biener'" <richard.guenther@gmail.com>
Cc: "GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: RE: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
Date: Mon, 17 Aug 2015 09:41:00 -0000	[thread overview]
Message-ID: <000001d0d8cf$2fb42770$8f1c7650$@arm.com> (raw)
In-Reply-To: <CAFiYyc1bgWwdV4PRLBuUv3yC0X-k5gJVuyyV9V7Vrz3Lte+wZw@mail.gmail.com>

Hi Richard,

Thanks for the reply. I'd chosen to add new expressions as this seemed more
consistent with the existing MAX_EXPR and MIN_EXPR tree codes. In addition it
would seem to provide more opportunities for optimisation than a target-specific
builtin implementation would. I accept that optimisation opportunities will
be more limited for strict math compilation, but that it was still worth having
them. Also, if we did map it to builtins then the scalar version would go
through the optabs and the vector version would go through the target's builtin
expansion, which doesn't seem very consistent.

Regards,
David.

> -----Original Message-----
> From: Richard Biener [mailto:richard.guenther@gmail.com]
> Sent: 13 August 2015 12:10
> To: David Sherwood
> Cc: GCC Patches
> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
> 
> On Thu, Aug 13, 2015 at 12:11 PM, David Sherwood <david.sherwood@arm.com> wrote:
> > Hi,
> >
> > Sorry to bother people again. Is this OK to go now?
> 
> Hmm, why don't you go the vectorized function call path for this,
> implementing the builtin_vectorized_function target hook?
> 
> Richard.
> 
> > Thanks!
> > David.
> >
> >> >
> >> > > On Mon, 29 Jun 2015, David Sherwood wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I have added new STRICT_MAX_EXPR and STRICT_MIN_EXPR expressions to support the
> >> > > > IEEE versions of fmin and fmax. This is done by recognising the math library
> >> > > > "fmax" and "fmin" builtin functions in a similar way to how this is done for
> >> > > > -ffast-math. This also allows us to vectorise the IEEE max/min functions for
> >> > > > targets that support it, for example aarch64/aarch32.
> >> > >
> >> > > This patch is missing documentation.  You need to document the new insn
> >> > > patterns in md.texi and the new tree codes in generic.texi.
> >> >
> >> > Hi, I've uploaded a new patch with the documentation. Hope this is ok.
> >>
> >> In various places where you refer to one operand being NaN, I think you
> >> mean one operand being a *quiet* NaN (if one is a signaling NaN - only
> >> supported by GCC if -fsignaling-nans - the IEEE minNum and maxNum
> >> operations raise "invalid" and return a quiet NaN).
> >
> > Hi, I have a new patch that hopefully addresses the documentation issues.
> >
> > Thanks,
> > David.
> >
> > ChangeLog:
> >
> > 2015-07-15  David Sherwood  <david.sherwood@arm.com>
> >
> > gcc/
> >     * builtins.c (integer_valued_real_p): Add STRICT_MIN_EXPR and
> >     STRICT_MAX_EXPR.
> >     (fold_builtin_fmin_fmax): For strict math, convert builting fmin and
> >     fmax to STRICT_MIN_EXPR and STRICT_MIN_EXPR, respectively.
> >     * expr.c (expand_expr_real_2): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR.
> >     * fold-const.c (const_binop): Likewise.
> >     (fold_binary_loc, tree_binary_nonnegative_warnv_p): Likewise.
> >     (tree_binary_nonzero_warnv_p): Likewise.
> >     * optabs.h (strict_minmax_support): Declare.
> >     * optabs.def: Add new optabs strict_max_optab/strict_min_optab.
> >     * optabs.c (optab_for_tree_code): Return new optabs for STRICT_MIN_EXPR
> >     and STRICT_MAX_EXPR.
> >     (strict_minmax_support): New function.
> >     * real.c (real_arithmetic): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR.
> >     * tree.def: Likewise.
> >     * tree.c (associative_tree_code, commutative_tree_code): Likewise.
> >     * tree-cfg.c (verify_expr): Likewise.
> >     (verify_gimple_assign_binary): Likewise.
> >     * tree-inline.c (estimate_operator_cost): Likewise.
> >     * tree-pretty-print.c (dump_generic_node, op_code_prio): Likewise.
> >     (op_symbol_code): Likewise.
> > gcc/config:
> >     * aarch64/aarch64.md: New pattern.
> >     * aarch64/aarch64-simd.md: Likewise.
> >     * aarch64/iterators.md: New unspecs, iterators.
> >     * arm/iterators.md: New iterators.
> >     * arm/unspecs.md: New unspecs.
> >     * arm/neon.md: New pattern.
> >     * arm/vfp.md: Likewise.
> > gcc/doc:
> >     * generic.texi: Add STRICT_MAX_EXPR and STRICT_MIN_EXPR.
> >     * md.texi: Add strict_min and strict_max patterns.
> > gcc/testsuite
> >     * gcc.target/aarch64/maxmin_strict.c: New test.
> >     * gcc.target/arm/maxmin_strict.c: New test.



  reply	other threads:[~2015-08-17  9:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 10:13 David Sherwood
2015-08-13 11:12 ` Richard Biener
2015-08-17  9:41   ` David Sherwood [this message]
2015-08-17 14:02     ` Richard Biener
2015-08-18 11:10       ` David Sherwood
2015-08-18 13:31         ` Richard Biener
2015-08-18 14:20           ` Richard Sandiford
2015-08-19  9:48             ` Richard Biener
2015-08-19 10:04               ` Richard Sandiford
2015-08-19 10:31                 ` Richard Biener
2015-08-19 12:23                   ` Richard Sandiford
2015-08-19 12:35                     ` Richard Biener
2015-08-19 13:16                       ` Richard Sandiford
2015-08-19 13:41                         ` Richard Biener
2015-09-14 10:47                           ` David Sherwood
2015-09-14 13:42                             ` Richard Biener
2015-09-14 20:38                               ` Joseph Myers
2015-08-19 15:32                       ` Joseph Myers
2015-11-23  9:21                       ` David Sherwood
2015-11-25 12:39                         ` Richard Biener
2015-08-19 15:07               ` Michael Matz
2015-08-19 15:25                 ` Richard Biener
2015-08-19 15:39                   ` Richard Sandiford
  -- strict thread matches above, loose matches on Subject: below --
2015-08-06  9:39 David Sherwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001d0d8cf$2fb42770$8f1c7650$@arm.com' \
    --to=david.sherwood@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).