public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: gcc-patches@gcc.gnu.org, segher@kernel.crashing.org,
	joseph@codesourcery.com, jakub@redhat.com, rguenther@suse.de,
	hp@bitrange.com, law@redhat.com, will_schmidt@vnet.ibm.com
Subject: Re: [PATCH v7] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]
Date: Wed, 15 Dec 2021 13:29:57 -0700	[thread overview]
Message-ID: <24a3a4aa-a728-fb92-284f-e2e24a271e30@gmail.com> (raw)
In-Reply-To: <20211124234847.tw7xh6pldu5me3mv@work-tp>



On 11/24/2021 4:48 PM, Raoni Fassina Firmino via Gcc-patches wrote:
> Changes since v6[6] and v5[5]:
>    - Based this version on the v5 one.
>    - Reworked all builtins back to the way they are in v5 and added the
>      following changes:
>      + Added a test to target libc, only expanding with glibc as the
>        target libc.
>      + Updated all three expanders header comment to reflect the added
>        behavior (fegetround got a full header as it had none).
>      + Added extra documentation for the builtins on doc/extend.texi,
>        similar to v6 version, but only the introductory paragraph,
>        without a dedicated entry for each, since now they behavior and
>        signature match the C99 ones.
>    - Changed the description for the return operand in the RTL template
>      of the fegetround expander.  Using "(set )", the same way as
>      rs6000_mffsl expander (this change was taken from v6).
>    - Updated the commit message mentioning the target libc restriction
>      and updated changelog.
>
> Tested on top of master (9bf69a8558638ce0cdd69e83a68776deb9b8e053)
> on the following plataforms with no regression:
>    - powerpc64le-linux-gnu (Power 9)
>    - powerpc64le-linux-gnu (Power 8)
>    - powerpc64-linux-gnu (Power 9, with 32 and 64 bits tests)
>
> Also made a visual test comparing the generated assembly of a test
> program built against glibc and musl (with -mmusl and with musl-gcc).
>
> Documentation changes tested on x86_64-redhat-linux.
>
> Well, turns out v6 was kind of a misstep[7].  But turns out the
> solution was in my face the whole time and Joseph was kind enough to
> spell it out to me.  I should have known, one can check for the target
> libc at runtime. It is a really simple addition to each expander, only
> expanding for the libcs the expander know the FE_* and can handle it.
> As Joseph mentioned on his review, with that the expander don't have
> to always expand and everything is fine.
>
> As I mentioned[8], musl and uclibc both uses the same values as glibc,
> I could add then enabling the expanders for them, not sure about it.
>
> I don't know if I should add something to the documentation, more
> precisely on section "6.59 Other Built-in Functions Provided by GCC"
> in doc/extend.text. Like I mentioned in v6 but I don't know if I'm
> doing it right, especially changing such a front facing documentation,
> but here it is.
>
> I'm repeating the "changelog" from past versions here for convenience:
>
> Changes since v5[5]:
>    - Reworked all builtins to accept the FE_* macros as parameters and
>      so be agnostic to libc implementations.  Largely based of
>      fpclassify.  To that end, there is some new files changed:
>      + Change the argument list for the builtins declarations in
>        builtins.def
>      + Added new types in builtin-types.def to use in the buitins
>        declarations.
>      + Added extra documentation for the builtins on doc/extend.texi,
>        similar to fpclassify.
>    - Updated doc/md.texi documentation with the new optab behaviors.
>    - Updated comments to the expanders and expand handlers to try to
>      explain whats is going on.
>    - Changed the description for the return operand in the RTL template
>      of the fegetround expander.  Using "(set )", the same way as
>      rs6000_mffsl expander.
>    - Updated testcases with helper macros with the new argument list.
>
> Changes since v4[4]:
>    - Fixed more spelling and code style.
>    - Add more clarification on  comments for feraiseexcept and
>      feclearexcept expands;
>
> Changes since v3[3]:
>    - Fixed fegetround bug on powerpc64 (big endian) that Segher
>      spotted;
>
> Changes since v2[2]:
>    - Added documentation for the new optabs;
>    - Remove use of non portable __builtin_clz;
>    - Changed feclearexcept and feraiseexcept to accept all 4 valid
>      flags at the same time and added more test for that case;
>    - Extended feclearexcept and feraiseexcept testcases to match
>      accepting multiple flags;
>    - Fixed builtin-feclearexcept-feraiseexcept-2.c testcase comparison
>      after feclearexcept tests;
>    - Updated commit message to reflect change in feclearexcept and
>      feraiseexcept from the glibc counterpart;
>    - Fixed English spelling and typos;
>    - Fixed code-style;
>    - Changed subject line tag to make clear it is not just rs6000 code.
>
> Changes since v1[1]:
>    - Fixed English spelling;
>    - Fixed code-style;
>    - Changed match operand predicate in feclearexcept and feraiseexcept;
>    - Changed testcase options;
>    - Minor changes in test code to be C90 compatible;
>    - Other minor changes suggested by Segher;
>    - Changed subject line tag (not sure if I tagged correctly or should
>      include optabs: also)
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552024.html
> [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553297.html
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557109.html
> [4] https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557349.html
> [5] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557984.html
> [6] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581837.html
> [7] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581929.html
> [8] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558070.html
>
> ---- 8< ----
>
> This optimizations were originally in glibc, but was removed
> and suggested that they were a good fit as gcc builtins[1].
>
> feclearexcept and feraiseexcept were extended (in comparison to the
> glibc version) to accept any combination of the accepted flags, not
> limited to just one flag bit at a time anymore.
>
> The builtin expanders needs knowledge of the target libc's FE_*
> values, so they are limited to expand only to suitable libcs.
>
> The associated bugreport: PR target/94193
>
> [1] https://sourceware.org/legacy-ml/libc-alpha/2020-03/msg00047.html
>      https://sourceware.org/legacy-ml/libc-alpha/2020-03/msg00080.html
>
> 2020-08-13  Raoni Fassina Firmino  <raoni@linux.ibm.com>
>
> gcc/ChangeLog:
>
>          * builtins.c (expand_builtin_fegetround): New function.
>          (expand_builtin_feclear_feraise_except): New function.
>          (expand_builtin): Add cases for BUILT_IN_FEGETROUND,
>          BUILT_IN_FECLEAREXCEPT and BUILT_IN_FERAISEEXCEPT
>          * config/rs6000/rs6000.md (fegetroundsi): New pattern.
>          (feclearexceptsi): New Pattern.
>          (feraiseexceptsi): New Pattern.
>          * doc/extend.texi: Add a new introductory paragraph about the
>          new builtins.
>          * doc/md.texi: (fegetround@var{m}): Document new optab.
>          (feclearexcept@var{m}): Document new optab.
>          (feraiseexcept@var{m}): Document new optab.
>          * optabs.def (fegetround_optab): New optab.
>          (feclearexcept_optab): New optab.
>          (feraiseexcept_optab): New optab.
>
> gcc/testsuite/ChangeLog:
>
>          * gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-1.c: New test.
>          * gcc.target/powerpc/builtin-feclearexcept-feraiseexcept-2.c: New test.
>          * gcc.target/powerpc/builtin-fegetround.c: New test.
I think the generic parts are fine once Segher is happy with the rest of 
the bits.

jeff


  parent reply	other threads:[~2021-12-15 20:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 23:48 Raoni Fassina Firmino
2021-11-25 21:12 ` Segher Boessenkool
2021-12-23 17:16   ` Raoni Fassina Firmino
2021-12-23 17:30     ` Raoni Fassina Firmino
2021-12-15 20:29 ` Jeff Law [this message]
2021-12-16  1:01   ` 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=24a3a4aa-a728-fb92-284f-e2e24a271e30@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hp@bitrange.com \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    --cc=rguenther@suse.de \
    --cc=segher@kernel.crashing.org \
    --cc=will_schmidt@vnet.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).