From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11854 invoked by alias); 26 Feb 2015 10:59:06 -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 11838 invoked by uid 89); 26 Feb 2015 10:59:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f170.google.com Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Feb 2015 10:59:04 +0000 Received: by mail-ob0-f170.google.com with SMTP id va2so10047668obc.1 for ; Thu, 26 Feb 2015 02:59:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.94.199 with SMTP id de7mr5460880oeb.23.1424948342807; Thu, 26 Feb 2015 02:59:02 -0800 (PST) Received: by 10.76.98.137 with HTTP; Thu, 26 Feb 2015 02:59:02 -0800 (PST) In-Reply-To: <20150226104241.GB1746@tucnak.redhat.com> References: <20150225161256.GT1746@tucnak.redhat.com> <20150225212231.GX1746@tucnak.redhat.com> <20150226104241.GB1746@tucnak.redhat.com> Date: Thu, 26 Feb 2015 11:03:00 -0000 Message-ID: Subject: Re: [PR58315] reset inlined debug vars at return-to point From: Richard Biener To: Jakub Jelinek Cc: Alexandre Oliva , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg01591.txt.bz2 On Thu, Feb 26, 2015 at 11:42 AM, Jakub Jelinek wrote: > On Thu, Feb 26, 2015 at 11:29:35AM +0100, Richard Biener wrote: >> I claim you can achieve the same result by effectively inserting >> those reset debug insns right before var-tracking itself and by >> re-computing BLOCK "liveness". That will automatically deal >> with code motion that extends the life-range of an inlined BLOCK >> by moving stmts (still associated with that BLOCK) across the >> return point of the inlined call (and thus across your debug resets). >> And it will allow var-tracking to eventually compute locations for >> vars at the "entry" of that BLOCK piece. > > If that would work, it would be nice, but I'm not sure how you can do that. > Using something like final.c (reemit_insn_block_notes) you can discover > the ranges of scopes (inline functions and lexical blocks). > If some scope has a single range, it is the easy case, you know where it > starts and where it ends. For scopes with multiple ranges, how can you find > out what case it is though? I mean, either it can be just the case that > some instruction(s) with different scope got scheduled (or sunk / whatever) > in between the instructions of the scope, in that case resetting the vars > there is highly undesirable (would majorly grow the .debug_loc lists and > break debuggers, e.g. when you try to watch some variable through the live > of some inline, if you reset it any time a single unrelated insn is > encountered, the debugger would need to tell you the var got lost/changed). > Or it can be the case of unrolled loop which has lexical scopes or inlines > in it, in that case you will have multiple "same" scopes, but in that case > it is unnecessary to preserve variables in between those, it is really > different inlines. I don't claim you can get the "maximal" pruning of the var-tracking solutions. I just claim that you can do something sensible by computing where BLOCKs go dead. And that this would be better than simply ignoring the code motion issue alltogether. If Alexs solution would be acceptable in terms of that issue then we can as well just insert debug resets for each variable at initial BLOCK boundaries. After all if the inliner inserts resets just for vars that already have debug stmts then I cook up a testcase where those debug stmts only appear after inlining. Indeed if we want to be as close to the source as possible we should insert debug stmts from the start (where the values are still computed) so that code-motion will simply make it unavailable (and also reset locations so you don't get gdb jumping around). Richard. > > Jakub