public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Jirui Wu <Jirui.Wu@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Richard Sandiford <Richard.Sandiford@arm.com>,
	 "ian@airs.com" <ian@airs.com>,
	Richard Biener <rguenther@suse.de>
Subject: Re: FW: [PING] Re: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) under -ffast-math on aarch64
Date: Fri, 15 Oct 2021 09:47:49 +0200	[thread overview]
Message-ID: <CAFiYyc0oCN1xrAtVjzWXcBLWjxDgS2eVQhw99YpEQyutr1UuSw@mail.gmail.com> (raw)
In-Reply-To: <VE1PR08MB48965E8D838E5A66176719708AA49@VE1PR08MB4896.eurprd08.prod.outlook.com>

On Fri, Sep 24, 2021 at 2:59 PM Jirui Wu via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi,
>
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577846.html
>
> The patch is attached as text for ease of use. Is there anything that needs to change?
>
> Ok for master? If OK, can it be committed for me, I have no commit rights.

I'm still not sure about the correctness.  I suppose the
flag_fp_int_builtin_inexact && !flag_trapping_math is supposed to guard
against spurious inexact exceptions, shouldn't that be
!flag_fp_int_builtin_inexact || !flag_trapping_math instead?

The comment looks a bit redundant and we prefer sth like

/* (double)(int)x -> trunc (x) if the type of x matches the
expressions FP type.  */

Thanks,
Richard.

> Jirui Wu
>
> -----Original Message-----
> From: Jirui Wu
> Sent: Friday, September 10, 2021 10:14 AM
> To: Richard Biener <rguenther@suse.de>
> Cc: Richard Biener <richard.guenther@gmail.com>; Andrew Pinski <pinskia@gmail.com>; Richard Sandiford <Richard.Sandiford@arm.com>; ian@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers <joseph@codesourcery.com>
> Subject: [PING] Re: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) under -ffast-math on aarch64
>
> Hi,
>
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577846.html
>
> Ok for master? If OK, can it be committed for me, I have no commit rights.
>
> Jirui Wu
> -----Original Message-----
> From: Jirui Wu
> Sent: Friday, September 3, 2021 12:39 PM
> To: 'Richard Biener' <rguenther@suse.de>
> Cc: Richard Biener <richard.guenther@gmail.com>; Andrew Pinski <pinskia@gmail.com>; Richard Sandiford <Richard.Sandiford@arm.com>; ian@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers <joseph@codesourcery.com>
> Subject: RE: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) under -ffast-math on aarch64
>
> Ping
>
> -----Original Message-----
> From: Jirui Wu
> Sent: Friday, August 20, 2021 4:28 PM
> To: Richard Biener <rguenther@suse.de>
> Cc: Richard Biener <richard.guenther@gmail.com>; Andrew Pinski <pinskia@gmail.com>; Richard Sandiford <Richard.Sandiford@arm.com>; ian@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers <joseph@codesourcery.com>
> Subject: RE: [Patch][GCC][middle-end] - Generate FRINTZ for (double)(int) under -ffast-math on aarch64
>
> > -----Original Message-----
> > From: Richard Biener <rguenther@suse.de>
> > Sent: Friday, August 20, 2021 8:15 AM
> > To: Jirui Wu <Jirui.Wu@arm.com>
> > Cc: Richard Biener <richard.guenther@gmail.com>; Andrew Pinski
> > <pinskia@gmail.com>; Richard Sandiford <Richard.Sandiford@arm.com>;
> > ian@airs.com; gcc-patches@gcc.gnu.org; Joseph S. Myers
> > <joseph@codesourcery.com>
> > Subject: RE: [Patch][GCC][middle-end] - Generate FRINTZ for
> > (double)(int) under -ffast-math on aarch64
> >
> > On Thu, 19 Aug 2021, Jirui Wu wrote:
> >
> > > Hi all,
> > >
> > > This patch generates FRINTZ instruction to optimize type casts.
> > >
> > > The changes in this patch covers:
> > > * Generate FRINTZ for (double)(int) casts.
> > > * Add new test cases.
> > >
> > > The intermediate type is not checked according to the C99 spec.
> > > Overflow of the integral part when casting floats to integers causes
> > undefined behavior.
> > > As a result, optimization to trunc() is not invalid.
> > > I've confirmed that Boolean type does not match the matching condition.
> > >
> > > Regtested on aarch64-none-linux-gnu and no issues.
> > >
> > > Ok for master? If OK can it be committed for me, I have no commit rights.
> >
> > +/* Detected a fix_trunc cast inside a float type cast,
> > +   use IFN_TRUNC to optimize.  */
> > +#if GIMPLE
> > +(simplify
> > +  (float (fix_trunc @0))
> > +  (if (direct_internal_fn_supported_p (IFN_TRUNC, type,
> > +                                      OPTIMIZE_FOR_BOTH)
> > +       && flag_unsafe_math_optimizations
> > +       && type == TREE_TYPE (@0))
> >
> > types_match (type, TREE_TYPE (@0))
> >
> > please.  Please perform cheap tests first (the flag test).
> >
> > +     (IFN_TRUNC @0)))
> > +#endif
> >
> > why only for GIMPLE?  I'm not sure flag_unsafe_math_optimizations is a
> > good test here.  If you say we can use undefined behavior of any
> > overflow of the fix_trunc operation what do we guard here?
> > If it's Inf/NaN input then flag_finite_math_only would be more
> > appropriate, if it's behavior for -0. (I suppose trunc (-0.0) == -0.0
> > and thus "wrong") then a && !HONOR_SIGNED_ZEROS (type) is missing
> > instead.  If it's setting of FENV state and possibly trapping on
> > overflow (but it's undefined?!) then flag_trapping_math covers the
> > latter but we don't have any flag for eliding FENV state affecting
> > transforms, so there the kitchen-sink flag_unsafe_math_optimizations might apply.
> >
> > So - which is it?
> >
> This change is only for GIMPLE because we can't test for the optab support without being in GIMPLE. direct_internal_fn_supported_p is defined only for GIMPLE.
>
> IFN_TRUNC's documentation mentions nothing for zero, NaNs/inf inputs.
> So I think the correct guard is just flag_fp_int_builtin_inexact.
> !flag_trapping_math because the operation can only still raise inexacts.
>
> The new pattern is moved next to the place you mentioned.
>
> Ok for master? If OK can it be committed for me, I have no commit rights.
>
> Thanks,
> Jirui
> > Note there's also the pattern
> >
> > /* Handle cases of two conversions in a row.  */ (for ocvt (convert
> > float
> > fix_trunc)  (for icvt (convert float)
> >   (simplify
> >    (ocvt (icvt@1 @0))
> >    (with
> >     {
> > ...
> >
> > which is related so please put the new pattern next to that (the set
> > of conversions handled there does not include (float (fix_trunc @0)))
> >
> > Thanks,
> > Richard.
> >
> > > Thanks,
> > > Jirui
> > >
> > > gcc/ChangeLog:
> > >
> > >         * match.pd: Generate IFN_TRUNC.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > >         * gcc.target/aarch64/merge_trunc1.c: New test.
> > >
> > > > -----Original Message-----
> > > > From: Richard Biener <richard.guenther@gmail.com>
> > > > Sent: Tuesday, August 17, 2021 9:13 AM
> > > > To: Andrew Pinski <pinskia@gmail.com>
> > > > Cc: Jirui Wu <Jirui.Wu@arm.com>; Richard Sandiford
> > > > <Richard.Sandiford@arm.com>; ian@airs.com;
> > > > gcc-patches@gcc.gnu.org; rguenther@suse.de
> > > > Subject: Re: [Patch][GCC][middle-end] - Generate FRINTZ for
> > > > (double)(int) under -ffast-math on aarch64
> > > >
> > > > On Mon, Aug 16, 2021 at 8:48 PM Andrew Pinski via Gcc-patches
> > > > <gcc- patches@gcc.gnu.org> wrote:
> > > > >
> > > > > On Mon, Aug 16, 2021 at 9:15 AM Jirui Wu via Gcc-patches
> > > > > <gcc-patches@gcc.gnu.org> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > This patch generates FRINTZ instruction to optimize type casts.
> > > > > >
> > > > > > The changes in this patch covers:
> > > > > > * Opimization of a FIX_TRUNC_EXPR cast inside a FLOAT_EXPR
> > > > > > using
> > > > IFN_TRUNC.
> > > > > > * Change of corresponding test cases.
> > > > > >
> > > > > > Regtested on aarch64-none-linux-gnu and no issues.
> > > > > >
> > > > > > Ok for master? If OK can it be committed for me, I have no
> > > > > > commit
> > rights.
> > > > >
> > > > > Is there a reason why you are doing the transformation manually
> > > > > inside forwprop rather than handling it inside match.pd?
> > > > > Also can't this only be done for -ffast-math case?
> > > >
> > > > You definitely have to look at the intermediate type - that could
> > > > be a uint8_t or even a boolean type.  So unless the intermediate
> > > > type can represent all float values optimizing to trunc() is invalid.
> > > > Also if you emit IFN_TRUNC you have to make sure there's target
> > > > support - we don't emit calls to a library
> > > > trunc() from an internal function call (and we wouldn't want to
> > > > optimize it that way).
> > > >
> > > > Richard.
> > > >
> > > > >
> > > > > Thanks,
> > > > > Andrew Pinski
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Jirui
> > > > > >
> > > > > > gcc/ChangeLog:
> > > > > >
> > > > > >         * tree-ssa-forwprop.c (pass_forwprop::execute):
> > > > > > Optimize with
> > frintz.
> > > > > >
> > > > > >
> > > > > > gcc/testsuite/ChangeLog:
> > > > > >
> > > > > >         * gcc.target/aarch64/fix_trunc1.c: Update to new expectation.
> > >
> >
> > --
> > Richard Biener <rguenther@suse.de>
> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409
> > Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

  reply	other threads:[~2021-10-15  7:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  9:14 Jirui Wu
2021-09-24 12:58 ` FW: " Jirui Wu
2021-10-15  7:47   ` Richard Biener [this message]
2021-10-18 23:22     ` Joseph Myers
2021-10-20 10:05       ` Andre Vieira (lists)
2021-10-20 10:20         ` Richard Biener

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=CAFiYyc0oCN1xrAtVjzWXcBLWjxDgS2eVQhw99YpEQyutr1UuSw@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=Jirui.Wu@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ian@airs.com \
    --cc=rguenther@suse.de \
    /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).