public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Hans-Peter Nilsson <hp@axis.com>,  <vmakarov@redhat.com>
Subject: Re: [PATCH] testsuite: Generalize check_effective_target_lra
Date: Wed, 08 Feb 2023 16:54:15 +0000	[thread overview]
Message-ID: <mptv8kc5c94.fsf@arm.com> (raw)
In-Reply-To: <20230207183813.978782042C@pchp3.se.axis.com> (Hans-Peter Nilsson via Gcc-patches's message of "Tue, 7 Feb 2023 19:38:13 +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.
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

  reply	other threads:[~2023-02-08 16:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 18:38 Hans-Peter Nilsson
2023-02-08 16:54 ` Richard Sandiford [this message]
2023-02-08 17:24   ` Hans-Peter Nilsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mptv8kc5c94.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hp@axis.com \
    --cc=vmakarov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).