On Fri, Jul 16, 2021 at 10:57 AM Matthias Kretz <m.kr...@gsi.de> wrote: > > On Wednesday, 14 July 2021 10:14:55 CEST Richard Biener wrote: > > > > There's one "related" IL feature used by the Fortran frontend - > > > > PAREN_EXPR > > > > prevents association across it. So for Fortran (when not > > > > -fno-protect-parens which is enabled by -Ofast), (a + b) - b cannot be > > > > optimized to a. Eventually this could be used to wrap intrinsic results > > > > since most of the issues in the end require association. Note > > > > PAREN_EXPR > > > > isn't exposed to the C family frontends but we could of course add a > > > > builtin-like thing for this _Noassoc ( .... ) or so. Note PAREN_EXPR > > > > survives -Ofast so it's the frontends that would need to choose to emit > > > > or > > > > not emit it (or always emit it). > > > > > > Interesting. I want that builtin in C++. Currently I use inline asm to > > > achieve a similar effect. But the inline asm hammer is really too big for > > > the problem. > > > > I think implementing it similar to how we do __builtin_shufflevector would > > be easily possible. PAREN_EXPR is a tree code. > > Like this? If you like it, I'll write the missing documentation and do real > regression testing.
Yes, like this. Now, __builtin_noassoc (a + b + c) might suggest that it prevents a + b + c from being re-associated - but it does not. PAREN_EXPR is a barrier for association, so for 'a + b + c + PAREN_EXPR <d + e + f>' the a+b+c and d+e+f chains will not mix but they individually can be re-associated. That said __builtin_noassoc might be a bad name, maybe __builtin_assoc_barrier is better? The implementation is originally for the Fortran language semantics which allows re-association but respects parens (thus PAREN_EXPR). To fully prevent association of a a + b + d + e chain you need at least two PAREN_EXPRs, for example (a+b) + (d+e) would do. One could of course provide __builtin_noassoc (a+b+c+d) with the implied semantics and insert PAREN_EXPRs around all operands when lowering it. Not sure what's more useful in practice - directly exposing the middle-end PAREN_EXPR or providing a way to mark a whole expression as to be not re-associated? Maybe both? 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-noassoc-1.c: New test. > > gcc/cp/ChangeLog: > > * cp-objcp-common.c (names_builtin_p): Handle > RID_BUILTIN_NOASSOC. > * parser.c (cp_parser_postfix_expression): Handle > RID_BUILTIN_NOASSOC. > > gcc/c-family/ChangeLog: > > * c-common.c (c_common_reswords): Add __builtin_noassoc. > * c-common.h (enum rid): Add RID_BUILTIN_NOASSOC. > > gcc/c/ChangeLog: > > * c-decl.c (names_builtin_p): Handle RID_BUILTIN_NOASSOC. > * c-parser.c (c_parser_postfix_expression): Likewise. > --- > 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 +++++++++++ > .../c-c++-common/builtin-noassoc-1.c | 24 +++++++++++++++++++ > 7 files changed, 62 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/c-c++-common/builtin-noassoc-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 > ──────────────────────────────────────────────────────────────────────────
