From: Richard Biener <rguenther@suse.de>
To: Matthias Kretz <m.kretz@gsi.de>
Cc: gcc-patches@gcc.gnu.org, jason@redhat.com,
"Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: [PATCH] c-family: Add __builtin_assoc_barrier
Date: Mon, 19 Jul 2021 14:34:12 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2107191425260.10711@zhemvz.fhfr.qr> (raw)
In-Reply-To: <2312888.R4OtGj9PrH@excalibur>
On Mon, 19 Jul 2021, Matthias Kretz wrote:
> tested on x86_64-pc-linux-gnu with no new failures. OK for master?
I think now that PAREN_EXPR can appear in C++ code you need to
adjust some machiner to expect it (constexpr folding? template stuff?).
I suggest to add some testcases covering templates and constexpr
functions.
+@deftypefn {Built-in Function} @var{type} __builtin_assoc_barrier
(@var{type} @var{expr})
+This built-in represents a re-association barrier for the floating-point
+expression @var{expr} with operations following the built-in. The
expression
+@var{expr} itself can be reordered, and the whole expression @var{expr}
can
be
+reordered with operations after the barrier.
What operations follow the built-in also applies to operations leading
the builtin? Maybe "This built-in represents a re-association barrier
for the floating-point expression @var{expr} with the expression
consuming its value." But I'm not an english speaker - I guess
I'm mostly confused about "follow" here.
I'm not sure if there are better C/C++ language terms describing what
the builtin does, but basically it appears as opaque operand to the
surrounding expression and the surrounding expression is opaque
to the expression inside the parens.
The barrier is only relevant
when
+@code{-fassociative-math} is active, since otherwise floating-point is
not
+treated as associative.
+
+@smallexample
+float x0 = a + b - b;
+float x1 = __builtin_assoc_barrier(a + b) - b;
+@end smallexample
+
+@noindent
+means that, with @code{-fassociative-math}, @code{x0} can be optimized to
+@code{x0 = a} but @code{x1} cannot.
+@end deftypefn
+
Otherwise the patch looks OK, but of course C/C++ frontend maintainers
would want to chime in here (I've CCed two).
Richard.
> New builtin to enable explicit use of PAREN_EXPR in C & C++ code.
>
> Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/builtin-assoc-barrier-1.c: New test.
>
> gcc/cp/ChangeLog:
>
> * cp-objcp-common.c (names_builtin_p): Handle
> RID_BUILTIN_ASSOC_BARRIER.
> * parser.c (cp_parser_postfix_expression): Handle
> RID_BUILTIN_ASSOC_BARRIER.
>
> gcc/c-family/ChangeLog:
>
> * c-common.c (c_common_reswords): Add __builtin_assoc_barrier.
> * c-common.h (enum rid): Add RID_BUILTIN_ASSOC_BARRIER.
>
> gcc/c/ChangeLog:
>
> * c-decl.c (names_builtin_p): Handle RID_BUILTIN_ASSOC_BARRIER.
> * c-parser.c (c_parser_postfix_expression): Likewise.
>
> gcc/ChangeLog:
>
> * doc/extend.texi: Document __builtin_assoc_barrier.
> ---
> gcc/c-family/c-common.c | 1 +
> gcc/c-family/c-common.h | 2 +-
> gcc/c/c-decl.c | 1 +
> gcc/c/c-parser.c | 20 ++++++++++++++++
> gcc/cp/cp-objcp-common.c | 1 +
> gcc/cp/parser.c | 14 +++++++++++
> gcc/doc/extend.texi | 18 ++++++++++++++
> .../c-c++-common/builtin-assoc-barrier-1.c | 24 +++++++++++++++++++
> 8 files changed, 80 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/c-c++-common/builtin-assoc-barrier-1.c
>
>
> --
> ──────────────────────────────────────────────────────────────────────────
> Dr. Matthias Kretz https://mattkretz.github.io
> GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
> std::experimental::simd https://github.com/VcDevel/std-simd
> ──────────────────────────────────────────────────────────────────────────
--
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-07-19 12:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-19 7:33 Matthias Kretz
2021-07-19 12:34 ` Richard Biener [this message]
2021-07-20 20:22 ` Jason Merrill
2021-09-06 12:21 ` [PATCH v2] " Matthias Kretz
2021-09-06 12:40 ` Richard Biener
2021-09-06 12:47 ` Matthias Kretz
2021-09-06 12:59 ` Richard Biener
2021-09-06 15:15 ` Matthias Kretz
2021-09-07 17:36 ` Jason Merrill
2021-09-08 9:37 ` Matthias Kretz
2021-09-08 13:44 ` Jason Merrill
2021-09-08 13:49 ` Matthias Kretz
2021-11-11 8:49 ` [PATCH v3] " Matthias Kretz
2021-11-17 18:35 ` Jason Merrill
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=nycvar.YFH.7.76.2107191425260.10711@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=joseph@codesourcery.com \
--cc=m.kretz@gsi.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).