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.kr...@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 <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
