From patchwork Sat Mar 18 16:23:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Segher Boessenkool X-Patchwork-Id: 740625 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vlnbv5lbLz9s1h for ; Sun, 19 Mar 2017 03:24:41 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="J4c8SGTN"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=Rnh54xUOcCqThX+9s Pl7fUV6MMXRWsbG8HQR8Z18EF3YCd2rfnLJxzEMSzUiYmaGXOEccYkN5ySXEX+gp EC7IIYU/eH5tHxoMPI53PG7ji0SNFGOKVtoEXla9t7tuSD4Wus2gANunXYN4/oZU RJt+ciiUZe5YShsO2OSnEQZ22w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=hBxJ5PtQwaAaXSQe3W3IK6G TbUg=; b=J4c8SGTNSYK+TKxxqkXLBJl8piDD/P8ibd3oACDh5NX1i3y4mNPgR7S 8FG7Gx3nIuYFV6JN3s49yL7iHZynlqiVsEMwHItep7I+VF2uCXAWUGLVpZMK+x/I sYQBGXPg8A5Uqi4Xy94Xd8Znzrmmd+2rtEu9Biwgs0RjXd7XHo9Y= Received: (qmail 63559 invoked by alias); 18 Mar 2017 16:24:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 61143 invoked by uid 89); 18 Mar 2017 16:24:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.5 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=uncommon, heart X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 18 Mar 2017 16:24:00 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v2IGNvP0019136; Sat, 18 Mar 2017 11:23:57 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v2IGNv3k019135; Sat, 18 Mar 2017 11:23:57 -0500 Date: Sat, 18 Mar 2017 11:23:56 -0500 From: Segher Boessenkool To: Jeff Law Cc: Bernd Schmidt , GCC Patches Subject: Re: Combiner fix for PR79910 Message-ID: <20170318162356.GY4402@gate.crashing.org> References: <15d38062-fd33-7de7-5bba-79f17adefc65@redhat.com> <5c9df1bf-65b3-c5bc-c350-f82466c3659b@redhat.com> <95129f0b-df37-a90f-af88-3d2392b88be4@redhat.com> <20170317221411.GU4402@gate.crashing.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes On Fri, Mar 17, 2017 at 04:23:57PM -0600, Jeff Law wrote: > >>+ /* For combinations that may result in two insns, we have to gather > >>+ some extra information about registers used, so that we can > >>+ update all relevant LOG_LINKS later. */ > > > >Please just refuse to do the combination in such cases instead. > ?!? That would essentially mean we can't do 3->2 combinations. No, only those that would lead to trouble. > >So, no, I'm not okay with this. It is very expensive, it is doing open > >heart surgery on combine's internal structures (in a way that may or may > >not work), and all that to combine some insns in a case that should not > >exist anyway. > Please don't be dramatic. If you've got a better suggestion for how to > fix this, be my guest. I don't like the compile-time cost either, but I > don't see a better solution. I'll commit the following monday or so: Subject: [PATCH] combine: Fix 79910 If the dest of an I0 or I1 is used in an insn before I2, as can happen in various uncommon cases, and we manage to do the combination, the set is moved to I2, which is wrong. Don't allow combining the insns in this case. This fixes the PR79910 testcase. I also tested building Linux kernels for all supported architectures: this fixes a bug for blackfin and makes no changes on other architectures. Bootstrapped and regression checked on x86_64-linux and powerpc64-linux {-m32,-m64}. Segher 2017-03-18 Segher Boessenkool PR rtl-optimization/79910 * combine.c (can_combine_p): Do not allow combining an I0 or I1 if its dest is used by an insn before I2 (other than the combined insns themselves, which are properly handled already). --- gcc/combine.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gcc/combine.c b/gcc/combine.c index 3e5c439..24ecedf 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -1953,6 +1953,10 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn *pred ATTRIBUTE_UNUSED, || (succ2 && FIND_REG_INC_NOTE (succ2, dest)) /* Don't substitute into a non-local goto, this confuses CFG. */ || (JUMP_P (i3) && find_reg_note (i3, REG_NON_LOCAL_GOTO, NULL_RTX)) + /* Make sure that DEST is not used after INSN but before SUCC, or + between SUCC and SUCC2. */ + || (succ && reg_used_between_p (dest, insn, succ)) + || (succ2 && reg_used_between_p (dest, succ, succ2)) /* Make sure that DEST is not used after SUCC but before I3. */ || (!all_adjacent && ((succ2