From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 916 invoked by alias); 1 Nov 2012 23:36:21 -0000 Received: (qmail 908 invoked by uid 22791); 1 Nov 2012 23:36:20 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qa0-f54.google.com (HELO mail-qa0-f54.google.com) (209.85.216.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Nov 2012 23:36:14 +0000 Received: by mail-qa0-f54.google.com with SMTP id s34so505410qat.20 for ; Thu, 01 Nov 2012 16:36:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=2xSXlMJb2YJiKY6OQjBAvkug5pfjGCvg8nnHlPuehEw=; b=aXcawbQ8hOcAG/dPN9ibLGS8QuwGueFVgmA2OPl4A0E5p9JGen/oLRALOg3yjxoP4u AMwlkaMr9imW7WR7cabo2/IpqTmCptrhRl6dxLV16+/uMRP9ly29mgwf4VAXeXYh3vYK OkNVWapQPUCeQUFsfg4VAtNVAo6HKAaFQdMPLSe16DC+2gbJuU+JzUomj7gDF3C+nWSf S5Linme5uaQOL/rixX/jjb5mffqHrmyiVtU+w30jj1IR0G3DxB8o+5b5uxihcKw0BES0 +fCAXXto2/Q+/ZMVHhZd5XXgg0EzqswTlfdepvh94OX3oNsUG93Ltpc0fWncew+eHOaj gjOA== MIME-Version: 1.0 Received: by 10.229.77.10 with SMTP id e10mr3712573qck.68.1351812974131; Thu, 01 Nov 2012 16:36:14 -0700 (PDT) Received: by 10.49.104.142 with HTTP; Thu, 1 Nov 2012 16:36:14 -0700 (PDT) In-Reply-To: References: <1826073.rNRXULK6yo@polaris> <3309385.mAl1npuha0@polaris> Date: Thu, 01 Nov 2012 23:36:00 -0000 Message-ID: Subject: Re: [PATCH] Reset source location for instructions moved out of its original residing basic block From: Xinliang David Li To: Dehao Chen Cc: Ian Lance Taylor , Eric Botcazou , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkyPaR5xFyfd0WBeRZnKPyT06owMpyldBmCoZflQbAL3QEnEO0SWq0rIHrPPOjXAoyDFPsgTruwUWE88DAKrF2uEZu988+WQMcTUw8nuk1GJoEy2awhSXHAJ4YjKRsirBVlDgHnwI+ke4jB+X5EZlb9HmuFygW3/rwKbpvagRuvs8Ls7RGS0+ZY2tqEGITvpt0ePN2C X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00160.txt.bz2 On Thu, Nov 1, 2012 at 4:16 PM, Dehao Chen wrote: > On Thu, Nov 1, 2012 at 4:07 PM, Xinliang David Li wrote: >> On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor wrote: >>> On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen wrote: >>>> >>>> I see your point. How about we guard these changes with a flag, say >>>> -gless-jumpy, so that people can always choose between better coverage >>>> and less jumpy gdb behavior (it's also important for some other >>>> clients like AutoFDO). I will have a series of patches to follow soon >>>> that can be guarded by this flag. >>> >>> This feels to me like an attempt to address the problem in the wrong >>> place. It seems to me that it would be better to do one of: >>> >>> * Use -Og and ensure that -Og does not move the code around. >>> Presumably this would lead to worse runtime performance and better >>> performance in the debugger. >>> >>> * Add heuristics to the debugger to jump around less. >>> >>> * Add a new debug facility to mark the statement as attached to a >>> particular source location, but moved relative to other source >>> locations. Add facilities to the debugger to take that into account. >>> >>> That said, I suppose I can imagine a mode like you suggest. It >>> shouldn't be a -g option, it should be a -f option, like >>> -fdiscard-moved-insn-debug-locations or something. That would be >>> along the lines of -fno-var-tracking: we generate worse debug info >>> upon user request. > > I don't see why debug info would be worse if we add something like > -fdiscard-moved-insn-debug-locations, as long as it is not turned on > by default. Any thoughts? > >>> >> >> Or have a common umbrella option to guard all changes that improves DOC. > > Is it like -Og approach as Ian mentioned? Yes, we can sacrifice some > performance (maybe 5%?) to get more accurate source level profile. But > if we plan to use AutoFDOed binary to collect AutoFDO profile, it'll > suffer the same debug problem again... No not the same as -Og -- DOC means debugging for fully optimized code. David > > Thanks, > Dehao > >> >> David >> >> >> >>> Ian