Message ID | 20230207183813.978782042C@pchp3.se.axis.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9C6723858C66 for <patchwork@sourceware.org>; Tue, 7 Feb 2023 18:38:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C6723858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675795124; 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=V1HbzMie9dnZUQ8+BQQfCWd3ZpRw5P1njUK/jKpG8zwqK0xDja5TCtfwN7uBvFhn4 bdWkTVmb1Ibo2wVqh9lRovOxkZtTH6hvAtPat0OGvY9gmZkOsK3bkZlLgtgZjKgQ/X 0v0WW6VsYoZCIMDaOvG7iCqNeoC75W9Xqw7rd0mw= 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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
testsuite: Generalize check_effective_target_lra
|
|
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