diff mbox series

testsuite: Fix up lra effective target

Message ID Zc819iVeHfLDZb5y@tucnak
State Unresolved
Headers
Series testsuite: Fix up lra effective target |

Checks

Context Check Description
snail/gcc-patch-check warning Git am fail log

Commit Message

Jakub Jelinek Feb. 16, 2024, 10:16 a.m. UTC 
  Hi!

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.

Ok for trunk?

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-16  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.


	Jakub

Comments

Mike Stump Feb. 16, 2024, 6:43 p.m. UTC | #1 
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> 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.
> 
> Ok for trunk?

Ok.
Mike Stump Feb. 16, 2024, 6:48 p.m. UTC | #2 
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> 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?

Since the port people have to maintain that code in general, I usually leave it to them to try and select a cheap, maintainable way to manage it.

If people want to pave the way, I'd tend to defer to them, having thought about more than I.
Hans-Peter Nilsson Feb. 26, 2024, 2:10 a.m. UTC | #3 
> Date: Fri, 16 Feb 2024 11:16:22 +0100
> From: Jakub Jelinek <jakub@redhat.com>

> 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.

Definitely, good riddance to that list.

I suggested a little over a year ago to generalize
check_effective_target_lra to get rid of that flawed target
list but was effectively shut down with a review request
that'd *keep* the faulty non-lra target list. :-(
"https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html"

TL;DR: I based LRA-ness on EBB being scanned in LRA but not
for reload (same empty foo), i.e. matching the string "EBB 2
3".  I don't know which method more stable, but that didn't
require -O2 nor -fdump-rtl-reload-details.

Having said that, I'm glad there's now a generic, working
(non-target-list-dependent) effective_target lra.

brgds, H-P
diff mbox series

Patch

--- gcc/testsuite/lib/target-supports.exp.jj	2024-02-15 09:51:34.591064180 +0100
+++ gcc/testsuite/lib/target-supports.exp	2024-02-16 10:50:29.986180603 +0100
@@ -13215,10 +13215,17 @@  proc check_effective_target_powerpc_as_p
 # 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