public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r14-9044] testsuite: Fix up lra effective target
Date: Sat, 17 Feb 2024 08:26:54 +0000 (GMT)	[thread overview]
Message-ID: <20240217082655.1E70D385700F@sourceware.org> (raw)

https://gcc.gnu.org/g:e16f90be2dc8af6c371fe79044c3e668fa3dda62

commit r14-9044-ge16f90be2dc8af6c371fe79044c3e668fa3dda62
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Feb 17 09:25:59 2024 +0100

    testsuite: Fix up lra effective target
    
    Given the recent discussions on IRC started with Andrew P. mentioning that
    an asm goto outputs test should have { target lra } and the lra effective
    target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
    we clearly have 14 other targets which don't support LRA and a couple of
    further ones which have an -mlra/-mno-lra switch (whatever default they
    have), seems to me the effective target is quite broken.
    
    The following patch rewrites it, such that it has a fast path for heavily
    used targets which are for years known to use only LRA (just an
    optimization) plus determines whether it is a LRA target or reload target
    by scanning the -fdump-rtl-reload-details dump on an empty function,
    LRA has quite a few always emitted messages in that case while reload has
    none of those.
    
    Tested on x86_64-linux and cross to s390x-linux, for the latter with both
    make check-gcc RUNTESTFLAGS='--target_board=unix/-mno-lra dg.exp=pr107385.c'
    where the test is now UNSUPPORTED and
    make check-gcc RUNTESTFLAGS='--target_board=unix/-mlra dg.exp=pr107385.c'
    where it fails because I don't have libc around.
    
    There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
    target.  I think claiming for it that it is a lra target is strange (even
    though it effectively returns true for targetm.lra_p ()), unsure if it
    supports asm goto with outputs or not, if it does and we want to test it,
    perhaps we should introduce asm_goto_outputs effective target and use
    lra || nvptx-*-* for that?
    
    2024-02-17  Jakub Jelinek  <jakub@redhat.com>
    
            * lib/target-supports.exp (check_effective_target_lra): Rewrite
            to list some heavily used always LRA targets and otherwise check the
            -fdump-rtl-reload-details dump for messages specific to LRA.

Diff:
---
 gcc/testsuite/lib/target-supports.exp | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 82c73faf7d89..6f4e25f280cb 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -13216,10 +13216,17 @@ proc check_effective_target_powerpc_as_p10_htm { } {
 # return 1 if LRA is supported.
 
 proc check_effective_target_lra { } {
-    if { [istarget hppa*-*-*] || [istarget avr-*-*] } {
-	return 0
+    # Start with heavily used targets which are known to always use LRA.
+    if { [istarget i?86-*-*] || [istarget x86_64-*-*]
+	 || [istarget aarch64*-*-*] || [istarget arm*-*-*]
+	 || [istarget powerpc*-*-*] || [istarget riscv*-*-*] } {
+	return 1
     }
-    return 1
+
+    # Otherwise check the reload dump for messages emitted solely by LRA.
+    return [check_no_messages_and_pattern lra "\\\*{9} Local #1: \\\*{9}" rtl-reload {
+        void foo (void) {}
+    } {-O2 -fdump-rtl-reload-details}] ;# LRA notes requires a detailed dump.
 }
 
 # Test whether optimizations are enabled ('__OPTIMIZE__') per the

                 reply	other threads:[~2024-02-17  8:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20240217082655.1E70D385700F@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /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).