Message ID | Zc819iVeHfLDZb5y@tucnak |
---|---|
State | New |
Headers | show |
Series | testsuite: Fix up lra effective target | expand |
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.
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.
> 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
--- 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