From patchwork Mon Oct 29 16:38:12 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Makarov X-Patchwork-Id: 195071 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 130C22C007E for ; Tue, 30 Oct 2012 03:38: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=1352133513; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=ltcvWs3Nk1avXgQVGL6jJQSCL0w=; b=snEw8UwNMq936rZ +iKfV+CgHYwozOAlYq6vSJfVmwZ/2ITZmRZUWvYIrKGJJ2PoWextrW0NG1Y7mQja 1+ixP7qqnEOkqAE8yAZ5IZgGTCJp9uuQq+OCfOuJbMHKuAo4w4Av8W4wWKG37HHu s08k/fHJrTD2qDJjJg/7Heftf7DI= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=qKG4/2gHIkeThk/uFciZITm+w1+1u8Em4HnCXH8ZqnAh2wvRuEoqqGHJAoIxc7 Bwps5CHYR+1LeizbXIa/XMessW3juOAL5PQ4zvoUETZaDs6N6JmT3qZe07yfBIbB GXTOTtcD5HHNvjduDswjFarkwR8rKkL4ACghM2AKRwk/g=; Received: (qmail 30523 invoked by alias); 29 Oct 2012 16:38:23 -0000 Received: (qmail 30381 invoked by uid 22791); 29 Oct 2012 16:38:21 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Oct 2012 16:38:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9TGcEIA023780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Oct 2012 12:38:14 -0400 Received: from Mair.local (vpn-11-173.rdu.redhat.com [10.11.11.173]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q9TGcDv3026947; Mon, 29 Oct 2012 12:38:13 -0400 Message-ID: <508EB0F4.2@redhat.com> Date: Mon, 29 Oct 2012 12:38:12 -0400 From: Vladimir Makarov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: GCC Patches , rdsandiford@googlemail.com Subject: Re: RFA: patch to fix PR55116 References: <508EA978.9060606@redhat.com> <87zk35i708.fsf@talisman.home> In-Reply-To: <87zk35i708.fsf@talisman.home> X-IsSubscribed: yes 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 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. Index: rtlanal.c =================================================================== --- rtlanal.c (revision 192942) +++ rtlanal.c (working copy) @@ -5459,6 +5459,12 @@ 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 + && !OBJECT_P (SUBREG_REG (*loc)) + && subreg_lowpart_p (*loc)) + /* (subreg (operator ...) ...) inside and is used for mode + conversion too. */ + loc = &XEXP (*loc, 0); else return loc; if (outer_code)