From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33044 invoked by alias); 20 Apr 2015 13:00:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 33030 invoked by uid 89); 20 Apr 2015 13:00:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 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-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 20 Apr 2015 13:00:41 +0000 Received: by pabtp1 with SMTP id tp1so206167874pab.2 for ; Mon, 20 Apr 2015 06:00:39 -0700 (PDT) X-Received: by 10.66.65.228 with SMTP id a4mr28323872pat.47.1429534839544; Mon, 20 Apr 2015 06:00:39 -0700 (PDT) Received: from bubble.grove.modra.org ([58.160.155.134]) by mx.google.com with ESMTPSA id in4sm18143137pbd.40.2015.04.20.06.00.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 06:00:38 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 0FA12EACABB; Mon, 20 Apr 2015 22:30:32 +0930 (ACST) Date: Mon, 20 Apr 2015 13:00:00 -0000 From: Alan Modra To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Alexandre Oliva Subject: Re: [Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc Message-ID: <20150420130032.GD12627@bubble.grove.modra.org> Mail-Followup-To: Jakub Jelinek , gcc-patches@gcc.gnu.org, Alexandre Oliva References: <20150420031049.GB12627@bubble.grove.modra.org> <20150420073507.GA1725@tucnak.redhat.com> <20150420084226.GC12627@bubble.grove.modra.org> <20150420085556.GE1725@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420085556.GE1725@tucnak.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01019.txt.bz2 On Mon, Apr 20, 2015 at 10:55:56AM +0200, Jakub Jelinek wrote: > On Mon, Apr 20, 2015 at 06:12:26PM +0930, Alan Modra wrote: > > I had it that way in my first patch, then decided to try deleting.. > > > > I can certainly change it back even if only to do it the standard way > > for safety's sake, but I'm curious as to why they can't be deleted in > > this special case. My thinking was that we're on a chain of blocks > > starting at the entry where there is a single outgoing live edge for > > the register being used. So there shouldn't be any need for a debug > > insn to mark info about the variable as invalid. > > The debug insns can be for arbitrary variables, there is no "the variable", Sure. > and there could be other debug insns for the same variable on that path, > say saying that decl lives in some other register, or can be computed using > an expression involving other registers, or memory etc. Say you could have Yes, that's true in the general case. For the shrink-wrap case, any bb (or tail of the entry block) that we move over has no use or def of the register. So I'm left wondering how it would be possible for the var to live in some other register or memory? Probably lack of imagination on my part, but the only scenarios I see would involve a failure of cse. Anyway, I rewrote the patch to do as you suggested, and started looking at .debug_loc in gcc/*.o for files that differed between the two approaches. (Only 32 files differed, besides the expected shrinkwrap.o and checksum files.) That was a bit of a revelation, and no wonder powerpc debugging is such a pain.. The first file I looked at was reload.o, and the first difference is in location lists for get_secondary_mem mode param. It looks like virgin: 000086c5 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4)) 000086d8 0000000000005cd7 0000000000005cd8 (DW_OP_GNU_entry_value: (DW_OP_reg4 (r4)); DW_OP_stack_value) 000086ee 0000000000005cd8 0000000000005cf8 (DW_OP_reg30 (r30)) 00008701 0000000000005d2c 0000000000005d38 (DW_OP_reg30 (r30)) delete: 000086ae 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4)) 000086c1 0000000000005cd7 0000000000005ec0 (DW_OP_GNU_entry_value: (DW_OP_reg4 (r4)); DW_OP_stack_value) zap: 000086ae 0000000000005c90 0000000000005cd7 (DW_OP_reg4 (r4)) 000086c1 0000000000005cd7 0000000000005cd8 (DW_OP_GNU_entry_value: (DW_OP_reg4 (r4)); DW_OP_stack_value) and the code: 5cd0: 48 00 00 01 bl 5cd0 <._Z17get_secondary_memP7rtx_def12machine_modei11reload_type+0x40> 5cd0: R_PPC64_REL24 _Z35rs6000_secondary_memory_needed_mode12machine_mode 5cd4: 60 00 00 00 nop 5cd8: 7c 7d 07 b4 extsw r29,r3 5cdc: 1f fd 00 1e mulli r31,r29,30 5ce0: 7d 3f da 14 add r9,r31,r27 5ce4: 79 29 1f 24 rldicr r9,r9,3,60 5ce8: 7d 3c 4a 14 add r9,r28,r9 5cec: e9 29 55 a8 ld r9,21928(r9) 5cf0: 2f a9 00 00 cmpdi cr7,r9,0 5cf4: 41 9e 00 3c beq cr7,5d30 <._Z17get_secondary_memP7rtx_def12machine_modei11reload_type+0xa0> 5cf8: 38 21 00 c0 addi r1,r1,192 5cfc: 7d 23 4b 78 mr r3,r9 ..rest of epilogue 5d30: 7b b9 1f 24 rldicr r25,r29,3,60 5d34: 7c 7e 1b 78 mr r30,r3 5d38: 7f 1c ca 14 add r24,r28,r25 Arrgh! In the first place the ranges are wrong since r4 dies after the bl, not the toc restoring nop. Worse, both deleting and zapping (ie UNKNOWN_VAR_LOC) the debug insn is wrong. My simplistic patch isn't correct. In fact it makes the debug info worse. However, leaving the debug insn alone says "mode" lives in r30, but that is wrong since the copy to r30 insn has been moved, to 5d34. Apparently the move causes the virgin location lists to say "mode" disappears at that point too. What a mess! Of course, all this moving for shrink-wrap is senseless in a block that contains a call. -- Alan Modra Australia Development Lab, IBM