Message ID | 20230207183813.978782042C@pchp3.se.axis.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3012223wrn; Tue, 7 Feb 2023 10:39:01 -0800 (PST) X-Google-Smtp-Source: AK7set8+ibLQ444ZRBQN0mSWZ4n3ScPdnezkHS0SzW1xMkRjJBB0iV9CZU/kYOsBn62+6AaADdom X-Received: by 2002:a17:906:f209:b0:878:6477:d7 with SMTP id gt9-20020a170906f20900b00878647700d7mr4435557ejb.72.1675795141149; Tue, 07 Feb 2023 10:39:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675795141; cv=none; d=google.com; s=arc-20160816; b=FNIqyz0doHfRdpiICX05ygXwCD208f73PdSye1izrA+4uq0SXA81985M5tS0cmNtC9 PHONF+WNxeFx6fCUIxOPhOzCrA18UlC1sPU/3HPU8Me3bvrq7TdT9hXHiscXXRv1/dnH IXmk0I2fX8ne4XfYJQaaIV84SNOhfYIHwVVrx2KIOgBhxHpDwkbfSr/u6MyiS1npur10 JktjC01o1OuKdpynP3QlepBW0KGa+7eGuAgbtcory/TXJUtHK6tlxRnRinSZy4KyQiey kpT8L5DVbg4MQxRhXlQ8JXcO1nSorDqGY+FW19bBJJaGcRljSzGaargXAdWBx65RM3Rx eKtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:date:message-id :content-transfer-encoding:mime-version:subject:cc:to:dmarc-filter :delivered-to:dkim-signature:dkim-filter; bh=6a8I/svYwfhK5UFgPyekHQj9fT2oots73NhA9RqRCig=; b=PvztwdZKZzUTDcL1AOK6IbOIzn+pq99csSFfW83FEKbmrzRyDhBNI4ACWCEAPxqg4k flQ4AZhh2ONFEbFNaiKsVi4Fi81VS7DzoF4U9EY87fxJKxyx+sl+C8l/ACHzST+c/NXI XBJ0TywdAD0ELvKmU4UEAsrQ7dpHTx1bPayfKln3rH6jUFD7OOMsz8NKhcLx4GUwBrVv X4sk/Z1Jn2+/5vxzKDsQAdKbFrJa3zUk8zE0dnKVjvnatMHVHs/60teT3XIFMSGzdFfE uMA3PSJlf/IGsG3mInF+KonmTfo2/K4q/GhIitQbh8Nr1PyPmN6wPMajjJ47IazS9uTX uKEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="BfYa/1So"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id ew23-20020a170907951700b00894e47adbb8si12293488ejc.835.2023.02.07.10.39.00 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Feb 2023 10:39:01 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="BfYa/1So"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4409F3858CDA for <ouuuleilei@gmail.com>; Tue, 7 Feb 2023 18:38:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4409F3858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675795139; bh=6a8I/svYwfhK5UFgPyekHQj9fT2oots73NhA9RqRCig=; h=To:CC:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=BfYa/1Soz9yBMR9TXDWgpQ9SsDpJbcjI8hsskPnqV8vrq+Z+/DL4C1onsk2V/Yrcj u7bYY50OsE8GeEp4x90KDIodTFhAt8NhQWL396OfutICV8gmhkWx7R5dUD6Vdp8RvM WRtIVD0h3wKIPJCzL6fLuYqRRVHhq/VGBnqT+wCo= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id B6DC43858D33 for <gcc-patches@gcc.gnu.org>; Tue, 7 Feb 2023 18:38:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B6DC43858D33 To: <gcc-patches@gcc.gnu.org> CC: <vmakarov@redhat.com> Subject: [PATCH] testsuite: Generalize check_effective_target_lra MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Message-ID: <20230207183813.978782042C@pchp3.se.axis.com> Date: Tue, 7 Feb 2023 19:38:13 +0100 X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Hans-Peter Nilsson <hp@axis.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757198566374783909?= X-GMAIL-MSGID: =?utf-8?q?1757198566374783909?= |
Series |
testsuite: Generalize check_effective_target_lra
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Hans-Peter Nilsson
Feb. 7, 2023, 6:38 p.m. UTC
Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and also hacked to switch to LRA). Ok to commit? --- 8< --- The LRA target list is incomplete. Rather than syncing it with actual LRA targets, better use existing infrastructure and look for a LRA-specific pattern in the reload dump (which has the same name, but completely different contents). * lib/target-supports.exp: Replace target list with looking for a LRA-specific string in the reload dump. --- gcc/testsuite/lib/target-supports.exp | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
Comments
Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and > also hacked to switch to LRA). Since !LRA is hopefully not long for this world, I'd personally prefer to keep it simple & obvious (at least for most targets). There's a risk that we could lose testing on most targets through an innocuous-looking change to one of LRA's fprintfs. If this is for -mlra-like options, I think it would be OK to guard the new code with a target check. So the patch is OK with the existing "return 0" replaced by the new return, and with the istarget list extended if necessary, but with the outer structure the same. That might not do what you want though... Thanks, Richard > > Ok to commit? > > --- 8< --- > The LRA target list is incomplete. Rather than syncing it with actual > LRA targets, better use existing infrastructure and look for a > LRA-specific pattern in the reload dump (which has the same name, but > completely different contents). > > * lib/target-supports.exp: Replace target list with looking for > a LRA-specific string in the reload dump. > --- > gcc/testsuite/lib/target-supports.exp | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp > index 227e3004077a..e62b7a2c869d 100644 > --- a/gcc/testsuite/lib/target-supports.exp > +++ b/gcc/testsuite/lib/target-supports.exp > @@ -12192,10 +12192,11 @@ proc check_effective_target_o_flag_in_section { } { > # return 1 if LRA is supported. > > proc check_effective_target_lra { } { > - if { [istarget hppa*-*-*] } { > - return 0 > - } > - return 1 > + # Iterating over extended basic blocks is new with LRA. Also need > + # a context to avoid spuriously matching a register name. > + return [check_no_messages_and_pattern lra "EBB 2 3" rtl-reload { > + void foo (void) { } > + }] > } > > # Test whether optimizations are enabled ('__OPTIMIZE__') per the
> From: Richard Sandiford <richard.sandiford@arm.com> > Date: Wed, 8 Feb 2023 17:54:15 +0100 > Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and > > also hacked to switch to LRA). > > Since !LRA is hopefully not long for this world, I'd personally > prefer to keep it simple & obvious (at least for most targets). > There's a risk that we could lose testing on most targets through > an innocuous-looking change to one of LRA's fprintfs. > > If this is for -mlra-like options, I think it would be OK to guard the > new code with a target check. So the patch is OK with the existing > "return 0" replaced by the new return, and with the istarget list > extended if necessary, but with the outer structure the same. If you, like me, are aiming for simple and obvious, why then complicate what already works "for -mlra-like options" with a target list? > That might not do what you want though... That assessment is correct. I'd rather the test-suite result be consistent for all targets. brgds, H-P PS. thanks for the review though > > Thanks, > Richard > > > > > Ok to commit? > > > > --- 8< --- > > The LRA target list is incomplete. Rather than syncing it with actual > > LRA targets, better use existing infrastructure and look for a > > LRA-specific pattern in the reload dump (which has the same name, but > > completely different contents). > > > > * lib/target-supports.exp: Replace target list with looking for > > a LRA-specific string in the reload dump. > > --- > > gcc/testsuite/lib/target-supports.exp | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp > > index 227e3004077a..e62b7a2c869d 100644 > > --- a/gcc/testsuite/lib/target-supports.exp > > +++ b/gcc/testsuite/lib/target-supports.exp > > @@ -12192,10 +12192,11 @@ proc check_effective_target_o_flag_in_section { } { > > # return 1 if LRA is supported. > > > > proc check_effective_target_lra { } { > > - if { [istarget hppa*-*-*] } { > > - return 0 > > - } > > - return 1 > > + # Iterating over extended basic blocks is new with LRA. Also need > > + # a context to avoid spuriously matching a register name. > > + return [check_no_messages_and_pattern lra "EBB 2 3" rtl-reload { > > + void foo (void) { } > > + }] > > } > > > > # Test whether optimizations are enabled ('__OPTIMIZE__') per the >
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 227e3004077a..e62b7a2c869d 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -12192,10 +12192,11 @@ proc check_effective_target_o_flag_in_section { } { # return 1 if LRA is supported. proc check_effective_target_lra { } { - if { [istarget hppa*-*-*] } { - return 0 - } - return 1 + # Iterating over extended basic blocks is new with LRA. Also need + # a context to avoid spuriously matching a register name. + return [check_no_messages_and_pattern lra "EBB 2 3" rtl-reload { + void foo (void) { } + }] } # Test whether optimizations are enabled ('__OPTIMIZE__') per the