public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dehao Chen <dehao@google.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Reset source location for instructions moved out of its original residing basic block
Date: Thu, 01 Nov 2012 14:36:00 -0000	[thread overview]
Message-ID: <CAO2gOZVa2oqXnj8q3sM3D7D6fV8xa-GvmgxBe7LRYk2Up6EGBA@mail.gmail.com> (raw)
In-Reply-To: <1826073.rNRXULK6yo@polaris>

On Thu, Nov 1, 2012 at 1:52 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> This patch tries to fix this problem by resetting the source location
>> when moving instructions to another BB. This can greatly improve the
>> debuggability of optimized code. For the attached unittest. Without
>> the patch, the debugger will always jump into line 14 even when the
>> branch at line 13 is not taken. With the patch, the problem is fixed.
>
> But this breaks coverage info!  You cannot change the source location of

For optimized code, there are many optimizations that can break
coverage info. Code motion is one of them. This patch actually tries
to fix the broken coverage info, as illustrated by the unittest.

> instructions randomly like that; the rule should be that, once a location is
> set, it cannot be changed.  At most it can be cleared.

If we clear the debug info for instructions moved to other BB, is it acceptable?

Thanks,
Dehao

>
>> gcc/ChangeLog:
>> 2012-10-31  Dehao Chen  <dehao@google.com>
>>
>>         * emit-rtl.c (reorder_insns): Reset the source location for
>>         instructions moved out of its original residing basic block.
>
> No, that isn't acceptable.
>
> --
> Eric Botcazou

  reply	other threads:[~2012-11-01 14:36 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 [this message]
2012-11-01 15:04     ` Eric Botcazou
2012-11-01 17:00       ` Dehao Chen
2012-11-01 22:57         ` Ian Lance Taylor
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=CAO2gOZVa2oqXnj8q3sM3D7D6fV8xa-GvmgxBe7LRYk2Up6EGBA@mail.gmail.com \
    --to=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).