From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E1C62385AC3F for ; Tue, 20 Jul 2021 20:22:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1C62385AC3F Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-517-ohTFMtLcNAS3yuHQgENh2w-1; Tue, 20 Jul 2021 16:22:06 -0400 X-MC-Unique: ohTFMtLcNAS3yuHQgENh2w-1 Received: by mail-pg1-f199.google.com with SMTP id n21-20020a6563d50000b029022866cd1f17so333252pgv.10 for ; Tue, 20 Jul 2021 13:22:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jrv63/5vFCTvYm3krRSUzcM2DeaoNwe3aYVsijsSjds=; b=kprjxv1nojD7kw8MWMigAS1vPhKKeYpoj+Yghp1ynYbulhU/ZT5ITGTsBJVJBMnnNB N0Id7GrpEu6VbNfIgv6/h1q9nQSZFRsvLM/u/F3tOteQ9EBMjyJ959+uT95gC2H1NBNI On2/e05q5CLkvD8Kp67XfyhpyT0RrppbaVxFI1/F8ivFnatS8YxAm43mVzVFuhDG5ZYA T616eFO8d/TlmGSs2J+SYbFbO5wwejU/qlw8/dT+x0OnaTvMnVacsr9j6i2HBWCADwjH +GvXCRS5QAldUefmwm8+s5spIyhm+n4BgQAPpuOHcG53Nn2LhB2prrb6HMqqRN7bbF4h iB9A== X-Gm-Message-State: AOAM5321nDteN1D+Mrz2Tfp/gtyq4rqTU+eqJS40EpLPHrcocBj4CRN0 yoRYs2IbRGhS+8mzk9LBcqvYnpViPhFgbXh8PcDwgeBqQPlKCbU2mhkp645j/QrxJ+PLLXvD0EG co6oqlpR/lLSOhH3VSw== X-Received: by 2002:a63:5244:: with SMTP id s4mr25545450pgl.267.1626812525716; Tue, 20 Jul 2021 13:22:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrn+dSosveDN6aUxBCs21JHod+vAMUzHDU+lGYyTf6XqP+iqeXD+3mvQ55OYQr7pNirdSIAw== X-Received: by 2002:a63:5244:: with SMTP id s4mr25545430pgl.267.1626812525352; Tue, 20 Jul 2021 13:22:05 -0700 (PDT) Received: from [192.168.0.62] (75-172-102-232.tukw.qwest.net. [75.172.102.232]) by smtp.gmail.com with ESMTPSA id s15sm24757294pfw.207.2021.07.20.13.22.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jul 2021 13:22:04 -0700 (PDT) Subject: Re: [PATCH] c-family: Add __builtin_assoc_barrier To: Richard Biener , Matthias Kretz Cc: gcc-patches@gcc.gnu.org, "Joseph S. Myers" References: <2312888.R4OtGj9PrH@excalibur> From: Jason Merrill Message-ID: Date: Tue, 20 Jul 2021 13:22:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 20:22:12 -0000 On 7/19/21 8:34 AM, Richard Biener wrote: > 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. Yes. The C++ front end already uses PAREN_EXPR in templates to indicate parenthesized initializers in cases where that matters for decltype(auto). It should be fine to use it for both that and __builtin_assoc_barrier, but you probably want to distinguish them with a TREE_LANG_FLAG, and change tsubst_copy_and_build to keep the PAREN_EXPR in this case. For constexpr you probably just need to add handling to cxx_eval_constant_expression to evaluate its operand instead. > +@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 >> >> 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 >> ────────────────────────────────────────────────────────────────────────── >