public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: will schmidt <will_schmidt@vnet.ibm.com>
To: Xionghu Luo <luoxhu@linux.ibm.com>, gcc-patches@gcc.gnu.org
Cc: wschmidt@linux.ibm.com, dje.gcc@gmail.com,
	segher@kernel.crashing.org, linkw@gcc.gnu.org
Subject: Re: Ping ^ 2: [PATCH] rs6000: Expand fmod and remainder when built with fast-math [PR97142]
Date: Fri, 09 Jul 2021 13:40:00 -0500	[thread overview]
Message-ID: <cdefffe51ef4173a4c95c3ac077b27a20d099f07.camel@vnet.ibm.com> (raw)
In-Reply-To: <ce4fcc41-f354-cba7-6ef4-74a5d9c0cfe3@linux.ibm.com>

On Wed, 2021-06-30 at 09:44 +0800, Xionghu Luo via Gcc-patches wrote:
> Gentle ping ^2, thanks.
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
> 
> 
> On 2021/5/14 15:13, Xionghu Luo via Gcc-patches wrote:
> > Test SPEC2017 Ofast P8LE for this patch : 511.povray_r +1.14%,
> > 526.blender_r +1.72%, no obvious changes to others.

Ok.

> > 
> > 
> > On 2021/5/6 10:36, Xionghu Luo via Gcc-patches wrote:
> > > Gentle ping, thanks.
> > > 
> > > 
> > > On 2021/4/16 15:10, Xiong Hu Luo wrote:
> > > > fmod/fmodf and remainder/remainderf could be expanded instead of library
> > > > call when fast-math build, which is much faster.
> > > > 
> > > > fmodf:
> > > >       fdivs   f0,f1,f2
> > > >       friz    f0,f0
> > > >       fnmsubs f1,f2,f0,f1
> > > > 
> > > > remainderf:
> > > >       fdivs   f0,f1,f2
> > > >       frin    f0,f0
> > > >       fnmsubs f1,f2,f0,f1
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > > 2021-04-16  Xionghu Luo  <luoxhu@linux.ibm.com>
> > > > 
> > > >     PR target/97142

That PR is " Bug 97142 
      - __builtin_fmod not optimized on POWER   "

OK.


> > > >     * config/rs6000/rs6000.md (fmod<mode>3): New define_expand.
> > > >     (remainder<mode>3): Likewise.


> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > 2021-04-16  Xionghu Luo  <luoxhu@linux.ibm.com>
> > > > 
> > > >     PR target/97142
> > > >     * gcc.target/powerpc/pr97142.c: New test.

Ok.

> > > > ---
> > > >   gcc/config/rs6000/rs6000.md                | 36 ++++++++++++++++++++++
> > > >   gcc/testsuite/gcc.target/powerpc/pr97142.c | 30 ++++++++++++++++++
> > > >   2 files changed, 66 insertions(+)
> > > >   create mode 100644 gcc/testsuite/gcc.target/powerpc/pr97142.c
> > > > 
> > > > diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> > > > index a1315523fec..7e0e94e6ba4 100644
> > > > --- a/gcc/config/rs6000/rs6000.md
> > > > +++ b/gcc/config/rs6000/rs6000.md
> > > > @@ -4902,6 +4902,42 @@ (define_insn "fre<sd>"
> > > >     [(set_attr "type" "fp")
> > > >      (set_attr "isa" "*,<Fisa>")])
> > > > +(define_expand "fmod<mode>3"
> > > > +  [(use (match_operand:SFDF 0 "gpc_reg_operand"))
> > > > +    (use (match_operand:SFDF 1 "gpc_reg_operand"))
> > > > +    (use (match_operand:SFDF 2 "gpc_reg_operand"))]
> > > > +  "TARGET_HARD_FLOAT
> > > > +  && TARGET_FPRND
> > > > +  && flag_unsafe_math_optimizations"
> > > > +{
> > > > +  rtx div = gen_reg_rtx (<MODE>mode);
> > > > +  emit_insn (gen_div<mode>3 (div, operands[1], operands[2]));
> > > > +
> > > > +  rtx friz = gen_reg_rtx (<MODE>mode);
> > > > +  emit_insn (gen_btrunc<mode>2 (friz, div));
> > > > +
> > > > +  emit_insn (gen_nfms<mode>4 (operands[0], operands[2], friz, 
> > > > operands[1]));
> > > > +  DONE;
> > > > + })
> > > > +
> > > > +(define_expand "remainder<mode>3"
> > > > +  [(use (match_operand:SFDF 0 "gpc_reg_operand"))
> > > > +    (use (match_operand:SFDF 1 "gpc_reg_operand"))
> > > > +    (use (match_operand:SFDF 2 "gpc_reg_operand"))]
> > > > +  "TARGET_HARD_FLOAT
> > > > +  && TARGET_FPRND
> > > > +  && flag_unsafe_math_optimizations"
> > > > +{
> > > > +  rtx div = gen_reg_rtx (<MODE>mode);
> > > > +  emit_insn (gen_div<mode>3 (div, operands[1], operands[2]));
> > > > +
> > > > +  rtx frin = gen_reg_rtx (<MODE>mode);
> > > > +  emit_insn (gen_round<mode>2 (frin, div));
> > > > +
> > > > +  emit_insn (gen_nfms<mode>4 (operands[0], operands[2], frin, 
> > > > operands[1]));
> > > > +  DONE;
> > > > + })

I notice the pattern of arguments to the final emit
is op[0],op[2],fri*,op[1]
while the description comment suggests the generated instruction 
will be fnmsubs  f1,f2,f0,f1  ;

I don't see any rearranging in the nfms<mode>4 expansions, but
presumably this is correct and just a cosmetic nit that catches my eye.

Ok.


> > > > +
> > > >   (define_insn "*rsqrt<mode>2"
> > > >     [(set (match_operand:SFDF 0 "gpc_reg_operand" "=<Ff>,wa")
> > > >       (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "<Ff>,wa")]
> > > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr97142.c 
> > > > b/gcc/testsuite/gcc.target/powerpc/pr97142.c
> > > > new file mode 100644
> > > > index 00000000000..48f25ca5b5b
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/powerpc/pr97142.c
> > > > @@ -0,0 +1,30 @@
> > > > +/* { dg-do compile } */
> > > > +/* { dg-options "-Ofast" } */
> > > > +
> > > > +#include <math.h>
> > > > +
> > > > +float test1 (float x, float y)
> > > > +{
> > > > +  return fmodf (x, y);
> > > > +}
> > > > +
> > > > +double test2 (double x, double y)
> > > > +{
> > > > +  return fmod (x, y);
> > > > +}
> > > > +
> > > > +float test3 (float x, float y)
> > > > +{
> > > > +  return remainderf (x, y);
> > > > +}
> > > > +
> > > > +double test4 (double x, double y)
> > > > +{
> > > > +  return remainder (x, y);
> > > > +}
> > > > +
> > > > +/* { dg-final { scan-assembler-not {\mbl fmod\M} } } */
> > > > +/* { dg-final { scan-assembler-not {\mbl fmodf\M} } } */
> > > > +/* { dg-final { scan-assembler-not {\mbl remainder\M} } } */
> > > > +/* { dg-final { scan-assembler-not {\mbl remainderf\M} } } */


Ok.
I'd be tempted to add scan-assembler checks for the fdivs,fri*,fnmsubs
instructions as well. 
I defer to others on that, of course.. :-) 

lgtm, 
thanks
-Will



> > > > +
> > > > 
> 
> 


  reply	other threads:[~2021-07-09 18:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  7:10 Xiong Hu Luo
2021-05-06  2:36 ` Ping: " Xionghu Luo
2021-05-14  7:13   ` Xionghu Luo
2021-06-07  5:08     ` Ping^2: " Xionghu Luo
2021-06-30  1:44     ` Ping ^ 2: " Xionghu Luo
2021-07-09 18:40       ` will schmidt [this message]
2021-07-12  1:25         ` Xionghu Luo
2021-09-03  2:31           ` Xionghu Luo
2021-09-03 14:51             ` Bill Schmidt
2021-09-03 14:53             ` David Edelsohn
2021-09-03 21:44             ` Segher Boessenkool
2021-09-06  8:59               ` Xionghu Luo
2021-09-06 21:57                 ` Segher Boessenkool

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=cdefffe51ef4173a4c95c3ac077b27a20d099f07.camel@vnet.ibm.com \
    --to=will_schmidt@vnet.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@gcc.gnu.org \
    --cc=luoxhu@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    --cc=wschmidt@linux.ibm.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).