From patchwork Thu Nov 17 01:51:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 60728 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D413A3954C6C for ; Thu, 17 Nov 2022 01:52:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D413A3954C6C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668649933; bh=mfRffxxIBjb6rxiJTlp/RyUZ9qeUQe7nc/FkDSGFOmg=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=fOlkDkiJ0HLTt5EDQNEtnjGrWUZJ26Mujs+8YiKGLXT3wOgSy+Kk7Xs2le55BxND+ bBswOa+Au8Fx9+z+O9AuZgFdfB90EXFgYdqcRsn+iaiv9pysNL/xLM3oKCQ8kj3n0F 5Hz9Ry4DFVipYjVpM37yuhNA5DLjlv4KUYRMLJ3E= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id D415C38A816A for ; Thu, 17 Nov 2022 01:51:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D415C38A816A Received: by mail-pg1-x531.google.com with SMTP id 136so678043pga.1 for ; Wed, 16 Nov 2022 17:51:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mfRffxxIBjb6rxiJTlp/RyUZ9qeUQe7nc/FkDSGFOmg=; b=VslIbnPv8MGUgbOeOxz1S1E4AKY7GcQ3EV8FiYIYEquGPauM0oB/YNcXAV3feCA1IM emreZCxrjQvNf6TbuZRVvGsdt4aj/owBeSEXTWZxs8Bul5+ZDMo8xqmS+CaaeZtRIbAQ rICymMrLXC0hj3n8meZAswsvl5ZxiDGfyXnEG0dduwA04KvxUnLST/QYkBZl2QnSrnnv D+YimlebWoooLpU70PGb1OmEjpmX/U3K236s+3yPJlpYkUibY9ikte3PXoSlU94tPm0T aMel3xcPd52aiVOcVZjy0dOqCtyAV7QYWhpVih934F9mw7Dua8lG303cby6LpSnNpBti mgTg== X-Gm-Message-State: ANoB5pmLVLkoOqPqIs8mSSayGHgPRQy6eIJ9iKsUwxPSDst3qfPv5edF fIE1aChIFB0z1OfRC8hLUcju43Is3Po= X-Google-Smtp-Source: AA0mqf4j1k7LrYqG/Xok9QXbX9XGVH+PFn6jYxRU1DQOLwAAd5HLAV0aZ5JAmR8AxOggrL5Z/jwBpQ== X-Received: by 2002:a62:2fc1:0:b0:562:fcae:5f10 with SMTP id v184-20020a622fc1000000b00562fcae5f10mr809045pfv.28.1668649900459; Wed, 16 Nov 2022 17:51:40 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id w13-20020a627b0d000000b0056ee49d6e95sm11522321pfc.86.2022.11.16.17.51.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Nov 2022 17:51:39 -0800 (PST) Message-ID: Date: Wed, 16 Nov 2022 18:51:38 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US Subject: [committed] Fix multiple recent sh3/sh3eb regressions To: "gcc-patches@gcc.gnu.org" X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jeff Law via Gcc-patches From: Jeff Law Reply-To: Jeff Law Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" 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 commit e214cab68cb34e77622b91113f7698cf137bbdd6 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 --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