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)
next prev parent 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).