From patchwork Wed Nov 26 18:54:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 415230 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 977EA14019D for ; Thu, 27 Nov 2014 05:54:29 +1100 (AEDT) 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:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=Kp+Im2bJaBxdMITtv lSnZpaxPFuxCpGH0o0uFyDc00NqoxL0rdESFvJd3Wm6Eqr6QlFr05pr8yqH3PlDR PZAM5Qgn1y3CtzD0yeJXHetGm/EbiRHp1ZSIDN3e4SUacputjkmlznV/kCFYMDF1 5WKllt8+EyJhqz/zINGClmZ/bw= 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:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=QZa+/3NxqqbC6UxA63c9Vw3 ndVU=; b=vOrgBJMi1lF6DJQgB3cSzyvvYbKb5b0FRAzy+zw4H4JjELZS7UwE7Bd WEgfqautqRbNLgjvQEqeFzEd+dyY9O4QXio3sb1Qy8M6BxR8oeWxVGkiARvVBzqg vy00HRKhJqW9nwGla1bKUekaoZ5OOg1dOMlb7pxMUtInIDjxJNW8= Received: (qmail 16143 invoked by alias); 26 Nov 2014 18:54:22 -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 16130 invoked by uid 89); 26 Nov 2014 18:54:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 26 Nov 2014 18:54:19 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAQIsINq011720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Nov 2014 13:54:18 -0500 Received: from tucnak.zalov.cz (ovpn-116-85.ams2.redhat.com [10.36.116.85]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAQIsGAO009512 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Nov 2014 13:54:18 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id sAQIsE5B013073; Wed, 26 Nov 2014 19:54:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id sAQIsDsF013030; Wed, 26 Nov 2014 19:54:13 +0100 Date: Wed, 26 Nov 2014 19:54:13 +0100 From: Jakub Jelinek To: Uros Bizjak , Richard Biener Cc: "gcc-patches@gcc.gnu.org" Subject: [PATCH] Fix find_base_term in 32-bit -fpic code (PR lto/64025, take 2) Message-ID: <20141126185413.GQ1669@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141124232539.GM1674@tucnak.redhat.com> <20141125082013.GO1674@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20141125082013.GO1674@tucnak.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes On Tue, Nov 25, 2014 at 09:20:13AM +0100, Jakub Jelinek wrote: > Actually, thinking about it more, at least according to > commutative_operand_precedence the canonical order is > what we used to return (i.e. (something - _G_O_T_) + (symbol_ref) > or > (something - _G_O_T_) + (const (symbol_ref +- const)) > So perhaps better fix is to follow find_base_value, which does something > like: > /* Guess which operand is the base address: > If either operand is a symbol, then it is the base. If > either operand is a CONST_INT, then the other is the base. */ > if (CONST_INT_P (src_1) || CONSTANT_P (src_0)) > return find_base_value (src_0); > else if (CONST_INT_P (src_0) || CONSTANT_P (src_1)) > return find_base_value (src_1); > and do something similar in find_base_term too. I.e. perhaps even with > higher precedence over REG_P with REG_POINTER (or lower, in these cases > it doesn't really matter, neither argument is REG_P), choose first > operand that is CONSTANT_P and not CONST_INT_P. Here it is. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-11-26 Jakub Jelinek PR lto/64025 * alias.c (find_base_term): Use std::swap. Prefer tmp2 if it is CONSTANT_P other than CONST_INT. Jakub --- gcc/alias.c.jj 2014-11-21 10:17:17.000000000 +0100 +++ gcc/alias.c 2014-11-26 12:31:24.719485590 +0100 @@ -1756,11 +1756,11 @@ find_base_term (rtx x) if (REG_P (tmp1) && REG_POINTER (tmp1)) ; else if (REG_P (tmp2) && REG_POINTER (tmp2)) - { - rtx tem = tmp1; - tmp1 = tmp2; - tmp2 = tem; - } + std::swap (tmp1, tmp2); + /* If second argument is constant which has base term, prefer it + over variable tmp1. See PR64025. */ + else if (CONSTANT_P (tmp2) && !CONST_INT_P (tmp2)) + std::swap (tmp1, tmp2); /* Go ahead and find the base term for both operands. If either base term is from a pointer or is a named object or a special address