From patchwork Tue Sep 9 11:50:27 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 387293 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 547311401DA for ; Tue, 9 Sep 2014 21:50:47 +1000 (EST) 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=Hh/Hhd56oTFBbzATI GCDNBVxehxosfeqygix9ESFODx2K69MxvEpJBe9ogG0VowPRhopQAMvBt9Zhdf3l yv63Yq4UxeQhPe5QCt/8WAa11omJgp/KWnjNtLQT/JpWmCXzA5MKGQMHE5vCWuXZ e0x7332k9SZ8xbFP1ut8Tx4H84= 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=7O8qDVw65lOVdFGdyPqA7BB dnCw=; b=Dl3sSSpAjiOfWJwBsIs2VW29Jfxwc7ay30FAJFbafGAwTFT0Ep6iBq+ LL4DdR9Kq3k1uw7GZDCtUAB2596LCKAIx6Aca+DIqqzVL7SWzvZJhA3XpLLCwjUT n2EKcwOZqwJqeuZeysrZRoT6HKGi6VmaQdTZuT0QShk//3T/OQDg= Received: (qmail 13646 invoked by alias); 9 Sep 2014 11:50:40 -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 13635 invoked by uid 89); 9 Sep 2014 11:50:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f44.google.com Received: from mail-pa0-f44.google.com (HELO mail-pa0-f44.google.com) (209.85.220.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 09 Sep 2014 11:50:38 +0000 Received: by mail-pa0-f44.google.com with SMTP id kx10so5293449pab.3 for ; Tue, 09 Sep 2014 04:50:36 -0700 (PDT) X-Received: by 10.66.140.76 with SMTP id re12mr14256709pab.141.1410263436514; Tue, 09 Sep 2014 04:50:36 -0700 (PDT) Received: from bubble.grove.modra.org ([58.160.155.134]) by mx.google.com with ESMTPSA id fz10sm11583929pdb.50.2014.09.09.04.50.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Sep 2014 04:50:35 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id E693DEA00F1; Tue, 9 Sep 2014 21:20:27 +0930 (CST) Date: Tue, 9 Sep 2014 21:20:27 +0930 From: Alan Modra To: gcc-patches@gcc.gnu.org Cc: "Maciej W. Rozycki" Subject: PR debug/60655, debug loc expressions Message-ID: <20140909115027.GR17693@bubble.grove.modra.org> Mail-Followup-To: gcc-patches@gcc.gnu.org, "Maciej W. Rozycki" References: <20140903053117.GF17693@bubble.grove.modra.org> <20140904122150.GL17693@bubble.grove.modra.org> <20140905013004.GN17693@bubble.grove.modra.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140905013004.GN17693@bubble.grove.modra.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On Fri, Sep 05, 2014 at 11:00:04AM +0930, Alan Modra wrote: > Of course it would be better to repair the damage done to debug info > rather than rejecting it outright.. This cures PR60655 on PowerPC by passing the horrible debug_loc expressions we have through simplify_rtx. Not only do we get reg10 + &.LANCHOR0 + const(0x14f - &.LANCHOR0) and reg10 + &modulus + const(~&d_data), the two expressions that cause the PR due to (CONST (MINUS ..)) and (CONST (NOT ..)), but also things like ~reg5 - reg31 + reg5 + reg10 + &modulus where "~reg5 + reg5" is an inefficient way to write "-1". It turns out that merely passing these expression through simplify_rtx isn't enough. Some tweaking is necessary to make (CONST (NOT ..)) and (CONST (MINUS ..)) recognised by simplify_plus_minus, and even after doing that, the two reg5 terms are not cancelled. The reg5 case starts off with the simplify_plus_minus sorted ops array effectively containing the expression -reg31 + reg10 + reg5 + -reg5 + &modulus + -1 The first combination tried is &modulus + -1, which is rejected to prevent recursion. The next combination tried is -reg5 + -1, which is simlified to ~reg5. Well, that is a valid simplification, but the trouble is that this prevents "reg5 + -reg5" being simplified to 0. What's more, "&modulus + -1" is no more expensive than "&modulus", since they are both emitted as an address field with a symbol+addend relocation. For that reason, I believe we should not consider combining a const_int with any other term after finding that it can be combined with a symbol_ref or other similar term. Bootstrapped and regression tested powerpc64-linux and x86_64-linux. I measured before/after bootstrap times on x86_64-linux because I was concerned about the extra simplify_rtx calls, and was pleasantly surprised to see a 0.23% improvement in bootstrap time. (Which of course is likely just noise.) OK to apply? PR debug/60655 * simplify-rtx.c (simplify_plus_minus): Delete unused "input_ops". Handle CONST wrapped NOT, NEG and MINUS. Break out of innermost loop when finding a trivial CONST expression. * var-tracking.c (vt_expand_var_loc_chain): Call simplify_rtx. Index: gcc/simplify-rtx.c =================================================================== --- gcc/simplify-rtx.c (revision 214487) +++ gcc/simplify-rtx.c (working copy) @@ -3960,7 +3960,7 @@ simplify_plus_minus (enum rtx_code code, enum mach { struct simplify_plus_minus_op_data ops[8]; rtx result, tem; - int n_ops = 2, input_ops = 2; + int n_ops = 2; int changed, n_constants = 0, canonicalized = 0; int i, j; @@ -3997,7 +3997,6 @@ simplify_plus_minus (enum rtx_code code, enum mach n_ops++; ops[i].op = XEXP (this_op, 0); - input_ops++; changed = 1; canonicalized |= this_neg; break; @@ -4010,14 +4009,35 @@ simplify_plus_minus (enum rtx_code code, enum mach break; case CONST: - if (n_ops < 7 - && GET_CODE (XEXP (this_op, 0)) == PLUS - && CONSTANT_P (XEXP (XEXP (this_op, 0), 0)) - && CONSTANT_P (XEXP (XEXP (this_op, 0), 1))) + if (GET_CODE (XEXP (this_op, 0)) == NEG + && CONSTANT_P (XEXP (XEXP (this_op, 0), 0))) { ops[i].op = XEXP (XEXP (this_op, 0), 0); + ops[i].neg = !this_neg; + changed = 1; + canonicalized = 1; + } + else if (n_ops < 7 + && GET_CODE (XEXP (this_op, 0)) == NOT + && CONSTANT_P (XEXP (XEXP (this_op, 0), 0))) + { + ops[n_ops].op = CONSTM1_RTX (mode); + ops[n_ops++].neg = this_neg; + ops[i].op = XEXP (XEXP (this_op, 0), 0); + ops[i].neg = !this_neg; + changed = 1; + canonicalized = 1; + } + else if (n_ops < 7 + && (GET_CODE (XEXP (this_op, 0)) == PLUS + || GET_CODE (XEXP (this_op, 0)) == MINUS) + && CONSTANT_P (XEXP (XEXP (this_op, 0), 0)) + && CONSTANT_P (XEXP (XEXP (this_op, 0), 1))) + { + ops[i].op = XEXP (XEXP (this_op, 0), 0); ops[n_ops].op = XEXP (XEXP (this_op, 0), 1); - ops[n_ops].neg = this_neg; + ops[n_ops].neg + = (GET_CODE (XEXP (this_op, 0)) == MINUS) ^ this_neg; n_ops++; changed = 1; canonicalized = 1; @@ -4141,16 +4161,21 @@ simplify_plus_minus (enum rtx_code code, enum mach else tem = simplify_binary_operation (ncode, mode, lhs, rhs); - /* Reject "simplifications" that just wrap the two - arguments in a CONST. Failure to do so can result - in infinite recursion with simplify_binary_operation - when it calls us to simplify CONST operations. */ - if (tem - && ! (GET_CODE (tem) == CONST - && GET_CODE (XEXP (tem, 0)) == ncode - && XEXP (XEXP (tem, 0), 0) == lhs - && XEXP (XEXP (tem, 0), 1) == rhs)) + if (tem) { + /* Reject "simplifications" that just wrap the two + arguments in a CONST. Failure to do so can result + in infinite recursion with simplify_binary_operation + when it calls us to simplify CONST operations. + Also, if we find such a simplification, don't try + any more combinations with this rhs: We must have + something like symbol+offset, ie. one of the + trivial CONST expressions we handle later. */ + if (GET_CODE (tem) == CONST + && GET_CODE (XEXP (tem, 0)) == ncode + && XEXP (XEXP (tem, 0), 0) == lhs + && XEXP (XEXP (tem, 0), 1) == rhs) + break; lneg &= rneg; if (GET_CODE (tem) == NEG) tem = XEXP (tem, 0), lneg = !lneg; Index: gcc/var-tracking.c =================================================================== --- gcc/var-tracking.c (revision 214898) +++ gcc/var-tracking.c (working copy) @@ -8375,7 +8375,15 @@ vt_expand_var_loc_chain (variable var, bitmap regs *pendrecp = pending_recursion; if (!pendrecp || !pending_recursion) - var->var_part[0].cur_loc = result; + { + if (result) + { + rtx tem = simplify_rtx (result); + if (tem) + result = tem; + } + var->var_part[0].cur_loc = result; + } return result; }