From patchwork Fri Nov 15 13:55:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kirill Yukhin X-Patchwork-Id: 291573 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)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1367A2C0079 for ; Sat, 16 Nov 2013 00:58:04 +1100 (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=Ob/7EoIb2sksfLeXm ouyOdfqVGQ7J2o/zjwHwXdMeiJH6vBjA0LrQ9d3lZpFXSN591kwiTSKgO16K2/iJ FZ+bjLOKJsW7XEGcX+CzHKoD+0YFd2Zu54za4DNSbzePyqCFwczyzgdvaIr4z2DY BHWRonCpXyj+0BysXGI/jdmrQE= 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=yR8yiJohWJTzYK+zL3x9oks zmT4=; b=Noh4ONnmi9vaqWVBe2Ny6Hrvw3t72eCTqj76Z+f4CI+89lmh6jFE5xO YZKZtgrxK6PGv+1DhBHSnhdAR7ZERRIuB6fde/vcwHjw9fqa3aQXGDDahDLQntbk zMvg06hsSAZV46XyOFj+XVFZRbHjoMuZihECcUEBQRgta57detdg= Received: (qmail 16694 invoked by alias); 15 Nov 2013 13:57:54 -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 16684 invoked by uid 89); 15 Nov 2013 13:57:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL, BAYES_50, FREEMAIL_FROM, MSGID_FROM_MTA_HEADER, RDNS_NONE, SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pa0-f48.google.com Received: from Unknown (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Nov 2013 13:57:53 +0000 Received: by mail-pa0-f48.google.com with SMTP id bj1so3608187pad.35 for ; Fri, 15 Nov 2013 05:57:45 -0800 (PST) X-Received: by 10.68.198.97 with SMTP id jb1mr6945442pbc.104.1384523865205; Fri, 15 Nov 2013 05:57:45 -0800 (PST) Received: from msticlxl57.ims.intel.com ([192.55.54.42]) by mx.google.com with ESMTPSA id qz9sm3429413pbc.3.2013.11.15.05.57.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:57:44 -0800 (PST) Date: Fri, 15 Nov 2013 16:55:59 +0300 From: Kirill Yukhin To: Eric Botcazou Cc: gcc-patches List , wilson@tuliptree.org, sellcey@mips.com, jtaylor.debian@gmail.com Subject: Re: [ia64] [PR target/57491] internal compiler error: in ia64_split_tmode -O2, quadmath Message-ID: <20131115135559.GA57982@msticlxl57.ims.intel.com> References: <20131107124234.GA2459@msticlxl57.ims.intel.com> <1890636.a2CkPapAFC@polaris> <20131115104509.GA52893@msticlxl57.ims.intel.com> <1986179.bTccpBNqBR@polaris> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1986179.bTccpBNqBR@polaris> Received: by 10.205.42.137 with HTTP; Fri, 15 Nov 2013 05:36:33 -0800 (PST) User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Hello, On 15 Nov 12:34, Eric Botcazou wrote: > > (insn 199 0 0 (set (reg:DI 14 r14) > > (mem:DI (post_inc:DI (reg/f:DI 15 r15 [447])) [3 > > *_61[_12]{lb: 1 sz: 64}.text+0 S8 A128])) -1 (nil)) > > (insn 200 199 0 (set (reg:DI 15 r15) > > (mem:DI (post_dec:DI (reg/f:DI 15 r15 [447])) [3 > > *_61[_12]{lb: 1 sz: 64}.text+8 S8 A64])) -1 (nil)) > > > > Although r15 post_dec in second insn seems to be useless code seems to be > > valid for me. What do you guys think? > > But the post_dec will clobber r15, won't it? As far as I understand semantics of this insn: (insn 200 199 0 (set (reg:DI 15 r15) (mem:DI (post_dec:DI (reg/f:DI 15 r15 [447])) [3 *_61[_12]{lb: 1 sz: 64}.text+8 S8 A64])) -1 (nil)) What is done is (in that sequence). 1. Calculate address of MEM: get r15 value. 2. Decrement r15 value. 3. Load MEM in to r15. Point 2 is useless as we kill it by 3. So, it is clobbered and as mention in comment this is sometimes ok to override pointer with pointer value. My patch was bogus in that I thought that `dead' actually means that if any part of address expression is changed - it becomes dead. PR example. We're trying to split this: (insn 77 180 79 4 (set (reg/v:TF 44 loc12 [orig:359 T8 ] [359]) (mem:TF (post_modify:DI (reg/f:DI 14 r14 [435]) (plus:DI (reg/f:DI 14 r14 [435]) (reg:DI 45 loc13 [orig:342 D.3347 ] [342]))) [2 *R1_102+0 S16 A128])) 1.i:2370 131 {*movtf_intern\ al} and we have intersect of destination (actually it is going to be a pair after split: ): (reg/v:TF 44 loc12 [orig:359 T8 ] [359]) and (mem:TF (post_modify:DI (reg/f:DI 14 r14 [435]) (plus:DI (reg/f:DI 14 r14 [435]) (reg:DI 45 loc13 [orig:342 D.3347 ] [342]))) If we take a look at these RTXes we see that they actually intersect by loc13, but this is *not* killing address in r14. Semantics which (will preserve r14 mem addr) is: 1. Calculate addr of MEM: get r14 value. 2. Set r14 += loc13. 3. Load value at r14 into . If this sequence is correct then we have live address in loc13 after insn. That is way setting `dead' in that case is incorrect. We need to set `dead' flag only when address is actually going to be killed by load. Patch in the bottom. Test from PR pass. Bootstrap (with Ada) is still in progress. --- Thanks, K --- gcc/config/ia64/ia64.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c index e6bd96d..d555ccc 100644 --- a/gcc/config/ia64/ia64.c +++ b/gcc/config/ia64/ia64.c @@ -1530,18 +1530,15 @@ ia64_split_tmode_move (rtx operands[]) && reg_overlap_mentioned_p (operands[0], operands[1])) { rtx base = XEXP (operands[1], 0); - rtx first_write = gen_rtx_REG (DImode, REGNO (operands[0])); while (GET_CODE (base) != REG) base = XEXP (base, 0); if (REGNO (base) == REGNO (operands[0])) - { - reversed = true; - first_write = gen_rtx_REG (DImode, REGNO (operands[0]) + 1); - } + reversed = true; - if (GET_CODE (operands[0]) == REG - && reg_overlap_mentioned_p (first_write, operands[1])) + if (refers_to_regno_p (REGNO (operands[0]), + REGNO (operands[0])+2, + base, 0)) dead = true; } /* Another reason to do the moves in reversed order is if the first