From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2119) id 532B0382E507; Thu, 17 Nov 2022 01:51:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 532B0382E507 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668649873; bh=MvxrSdkyMzWYdEsXwK7/+Irfy+eydspOvf+6uMakg0Y=; h=From:To:Subject:Date:From; b=eAbXxrklgijq+7QkXISUmQYHxv83BYAd1V57H18BYdAfYvyhhqwtH29BlLK0QA8fM xsLVJjln3+CH3+siGbBZob3i9zRgmgihSoGnYsJSZI3XIxcQYZiFqrgQJtoARjLTeJ DoN38Glme/Kfe00YWa6scIVb6bFhuF+ggCW5YBcs= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Jeff Law To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-4118] Fix multiple recent sh3/sh3eb regressions X-Act-Checkin: gcc X-Git-Author: Jeff Law X-Git-Refname: refs/heads/master X-Git-Oldrev: f69a8299c1d95548e1539227fb7b8f5581aeb29b X-Git-Newrev: e214cab68cb34e77622b91113f7698cf137bbdd6 Message-Id: <20221117015113.532B0382E507@sourceware.org> Date: Thu, 17 Nov 2022 01:51:13 +0000 (GMT) List-Id: https://gcc.gnu.org/g:e214cab68cb34e77622b91113f7698cf137bbdd6 commit r13-4118-ge214cab68cb34e77622b91113f7698cf137bbdd6 Author: Jeff Law 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: --- gcc/config/sh/sh_treg_combine.cc | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) 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