[committed] Fix multiple recent sh3/sh3eb regressions

[Jeff Law <jeffreyalaw@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]


So my tester started showing even more regressions on the sh3/sh4 runs 
recently (beyond the one recently reported in BZ triggered by some DCE 
related changes).  Bisection kept showing inconsistent results.  I was 
starting to think memory management error, but valgrind didn't flag 
anything.

After a bit of head-banging I was able to track it down to predicate 
tests called from the SH specific combiner passes.  And once I started 
getting inside the actual code for the predicate function it became 
pretty obvious.  The predicate routines are supposed to return a bool, 
fine and they dutifully set the low bit in %eax properly.

The *caller* was looking at the full register.  Uh-oh.  Naturally we 
became dependent on what happened to be in the upper 31 bits of a 
register.  That's why the bug would come and go so willy-nilly. This was 
ultimately chased down to an incorrect prototype in sh_treg_combine.cc  
for predicates functions defined via define_predicate.

Removing the bogus prototypes and instead including the generated 
tm-preds.h fixes this problem.  I also checked the other ports for 
similar problems (specifically looking for a extern int.*_operand, then 
for each of the hits looking to see if the predicate was defined via 
define_predicate).  No other ports had similar braindamage.

This fixes the most recent regressions in my tester for sh3/sh3eb and I 
strongly suspect sh4.  It does not fix 107704, but I think Richi and I 
both agree that's a visitation order issue and we were just getting 
lucky before.


Committing to the trunk.



Jeff

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 2791 bytes --]

commit e214cab68cb34e77622b91113f7698cf137bbdd6
Author: Jeff Law <jlaw@ventanamicro.com>
Date:   Wed Nov 16 18:47:59 2022 -0700

    Fix multiple recent sh3/sh3eb regressions
    
    So my tester started showing even more regressions on the sh3/sh4 runs
    recently (beyond the one recently reported in BZ triggered by some DCE
    related changes).  Bisection kept showing inconsistent results.  I was
    starting to think memory management error, but valgrind didn't flag anything.
    
    After a bit of head-banging I was able to track it down to predicate
    tests called from the SH specific combiner passes.  And once I started
    getting inside the actual code for the predicate function it became
    pretty obvious.  The predicate routines are supposed to return a bool,
    fine and they dutifully set the low bit in %eax properly.
    
    The *caller* was looking at the full register.  Uh-oh.  Naturally we
    became dependent on what happened to be in the upper 31 bits of a register.
    That's why the bug would come and go so willy-nilly.  This was ultimately
    chased down to an incorrect prototype in sh_treg_combine.cc for predicate
    functions defined via define_predicate.
    
    Removing the bogus prototypes and instead including the generated
    tm-preds.h fixes this problem.  I also checked the other ports for
    similar problems (specifically looking for a extern int.*_operand, then
    for each of the hits looking to see if the predicate was defined via
    define_predicate).  No other ports had similar braindamage.
    
    This fixes the most recent regressions in my tester for sh3/sh3eb
    and I strongly suspect sh4.  It does not fix 107704, but I think
    Richi and I both agree that's a visitation order issue and we were
    just getting lucky before.
    
    gcc/
    
            * config/sh/sh_treg_combine.cc: Include tm-preds.h.
            (t_reg_operand): Remove bogus prototype.
            (negt_reg_operand): Likewise.

diff --git a/gcc/config/sh/sh_treg_combine.cc b/gcc/config/sh/sh_treg_combine.cc
index f6553c04a0d..ab7dc5d4985 100644
--- a/gcc/config/sh/sh_treg_combine.cc
+++ b/gcc/config/sh/sh_treg_combine.cc
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgrtl.h"
 #include "tree-pass.h"
 #include "expr.h"
+#include "tm-preds.h"
 
 /*
 This pass tries to optimize for example this:
@@ -426,10 +427,6 @@ is_conditional_insn (rtx_insn* i)
   return GET_CODE (p) == SET && GET_CODE (XEXP (p, 1)) == IF_THEN_ELSE;
 }
 
-// FIXME: Remove dependency on SH predicate function somehow.
-extern int t_reg_operand (rtx, machine_mode);
-extern int negt_reg_operand (rtx, machine_mode);
-
 // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 // RTL pass class