From patchwork Tue Oct 30 11:09:58 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 195444 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]) by ozlabs.org (Postfix) with SMTP id 2FBA42C00B4 for ; Tue, 30 Oct 2012 22:10:32 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1352200233; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=AaTVm8+BP70nSCm0pfsP Mm1Vpwo=; b=XHT2DetVcbqPudpc/Ok7ZsCTkHCmtqJYqNwRvQ6PhIePiyK9xQbF 5nIOqrjAxSrGzrRMxapaQb3VXsT3YlA1Ff0stDkgBMZFbG0llQ2l9s8PZqT+YGjL ZAivC7tmumW8/2wfxpEdeiPNKKF0CpgNHyART+qeqvQn3yvkNOG4PTk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Mail-Followup-To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=NdU15CQpWuVpm9ZN8QHnvWV+v5FeflD0eg2N35OAa2U6IBSwjv3zyhwt8Ho0eH LivGoDxTdtIGIj3c1LIClcQfpFSTMq8zWfvo6/xF4G+uo8zKmDeOI6P82FYr21QQ ShTIft+8EAQPNDfOplD2SzKqwIR9biE5Grrx4BJOJ9eSI=; Received: (qmail 10425 invoked by alias); 30 Oct 2012 11:10:18 -0000 Received: (qmail 10412 invoked by uid 22791); 30 Oct 2012 11:10:17 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL, BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KHOP_RCVD_TRUST, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ee0-f47.google.com (HELO mail-ee0-f47.google.com) (74.125.83.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Oct 2012 11:10:04 +0000 Received: by mail-ee0-f47.google.com with SMTP id t10so86118eei.20 for ; Tue, 30 Oct 2012 04:10:03 -0700 (PDT) Received: by 10.14.0.68 with SMTP id 44mr73024076eea.1.1351595403077; Tue, 30 Oct 2012 04:10:03 -0700 (PDT) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com. [195.212.29.75]) by mx.google.com with ESMTPS id f3sm837537eeo.13.2012.10.30.04.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 04:10:00 -0700 (PDT) From: Richard Sandiford To: "H.J. Lu" Mail-Followup-To: "H.J. Lu" , Vladimir Makarov , GCC Patches , rdsandiford@googlemail.com Cc: Vladimir Makarov , GCC Patches Subject: Re: RFA: patch to fix PR55116 References: <508EA978.9060606@redhat.com> <87zk35i708.fsf@talisman.home> <508EB0F4.2@redhat.com> Date: Tue, 30 Oct 2012 11:09:58 +0000 In-Reply-To: (H. J. Lu's message of "Mon, 29 Oct 2012 23:02:05 -0700") Message-ID: <87390wcj21.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 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 "H.J. Lu" writes: > On Mon, Oct 29, 2012 at 5:11 PM, H.J. Lu wrote: >> On Mon, Oct 29, 2012 at 4:41 PM, H.J. Lu wrote: >>> On Mon, Oct 29, 2012 at 9:38 AM, Vladimir Makarov >>> wrote: >>>> On 12-10-29 12:21 PM, Richard Sandiford wrote: >>>>> >>>>> Vladimir Makarov writes: >>>>>> >>>>>> H.J. in >>>>>> >>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55116 >>>>>> >>>>>> reported an interesting address >>>>>> >>>>>> (and:DI (subreg:DI (plus:SI (ashift:SI (reg:SI 96 [ glob_vol_int.22 ]) >>>>>> (const_int 2 [0x2])) >>>>>> (symbol_ref:SI ("glob_vol_int_arr") >>>>> 0x7ffff03c2720 glob_vol_int_arr>)) 0) >>>>>> (const_int 4294967295 [0xffffffff])) >>>>>> >>>>>> which can not be correctly extracted. Here `and' with `subreg' >>>>>> behaves as an address mutation. >>>>>> >>>>>> The following patch fixes the problem. >>>>>> >>>>>> Ok to commit, Richard? >>>>> >>>>> Heh, I wondered if subregs might still be used like that, and was almost >>>>> tempted to add them just in case. >>>>> >>>>> I think this particular case is really a failed canonicalisation and that: >>>>> >>>>> (and:DI (subreg:DI (foo:SI ...) 0) (const_int 0xffffffff)) >>>>> >>>>> ought to be: >>>>> >>>>> (zero_extend:DI (foo:SI ...)) >>>> >>>> Yes, that was my thought too. >>>> >>>>> But I know I've approved MIPS patches to accept >>>>> (and:DI ... (const_int 0xffffffff)) as an alternative. >>>>> >>>>>> Index: rtlanal.c >>>>>> =================================================================== >>>>>> --- rtlanal.c (revision 192942) >>>>>> +++ rtlanal.c (working copy) >>>>>> @@ -5459,6 +5459,11 @@ strip_address_mutations (rtx *loc, enum >>>>>> else if (code == AND && CONST_INT_P (XEXP (*loc, 1))) >>>>>> /* (and ... (const_int -X)) is used to align to X bytes. */ >>>>>> loc = &XEXP (*loc, 0); >>>>>> + else if (code == SUBREG >>>>>> + && ! REG_P (XEXP (*loc, 0)) && ! MEM_P (XEXP (*loc, 0))) >>>>>> + /* (subreg (operator ...) ...) usually inside and is used for >>>>>> + mode conversion too. */ >>>>>> + loc = &XEXP (*loc, 0); >>>>> >>>>> I think the condition should be: >>>>> >>>>> else if (code == SUBREG >>>>> && !OBJECT_P (SUBREG_REG (*loc)) >>>>> && subreg_lowpart (*loc)) >>>>> >>>>> OK with that change, if it works. >>>>> >>>> Yes, it works. >>>> I've submitted the following patch. >>>> >>> >>> It doesn't work right. I will create a new testcase. >>> >> >> > > This patch limits SUBREG to Pmode. Tested on Linux/x86-64. > OK to install? > > Thanks. The address in this case is: (plus:SI (mult:SI (reg/v:SI 223 [orig:154 j ] [154]) (const_int 8 [0x8])) (subreg:SI (plus:DI (reg/f:DI 20 frame) (const_int 32 [0x20])) 0)) which after Uros's subreg simplification patch shouldn't be allowed: the subreg ought to be on the frame register rather than the plus. The attached patch seems to work for the testcase. Does it work more generally? Richard gcc/ * lra-eliminations.c (lra_eliminate_regs_1): Use simplify_gen_subreg rather than gen_rtx_SUBREG. Index: gcc/lra-eliminations.c =================================================================== --- gcc/lra-eliminations.c (revision 192983) +++ gcc/lra-eliminations.c (working copy) @@ -550,7 +550,8 @@ return x; } else - return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x)); + return simplify_gen_subreg (GET_MODE (x), new_rtx, + GET_MODE (new_rtx), SUBREG_BYTE (x)); } return x;