public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Dehao Chen <dehao@google.com>
Cc: Eric Botcazou <ebotcazou@adacore.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
		David Li <davidxl@google.com>
Subject: Re: [PATCH] Reset source location for instructions moved out of its original residing basic block
Date: Thu, 01 Nov 2012 22:57:00 -0000	[thread overview]
Message-ID: <CAKOQZ8xzPzLV3JWT1ytT5QzWo2Dk3X+9cSkC1Gyz2u45VJy25A@mail.gmail.com> (raw)
In-Reply-To: <CAO2gOZUdXaj6X-nqJaYUiX9vBnVMANzKeW3eADvxcJNPLpCdnA@mail.gmail.com>

On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen <dehao@google.com> 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.

Ian

  reply	other threads:[~2012-11-01 22:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-01  5:03 Dehao Chen
2012-11-01  8:56 ` Eric Botcazou
2012-11-01 14:36   ` Dehao Chen
2012-11-01 15:04     ` Eric Botcazou
2012-11-01 17:00       ` Dehao Chen
2012-11-01 22:57         ` Ian Lance Taylor [this message]
2012-11-01 23:07           ` Xinliang David Li
2012-11-01 23:16             ` Dehao Chen
2012-11-01 23:36               ` Xinliang David Li
2012-11-04 22:26         ` Alexandre Oliva
2012-11-26 14:47           ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKOQZ8xzPzLV3JWT1ytT5QzWo2Dk3X+9cSkC1Gyz2u45VJy25A@mail.gmail.com \
    --to=iant@google.com \
    --cc=davidxl@google.com \
    --cc=dehao@google.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).