This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR54693] loss of debug info in jump threading and loop ivopts


On Nov  1, 2012, Jakub Jelinek <jakub@redhat.com> wrote:

> Even for stmt frontiers it is IMHO undesirable to duplicate
> (perhaps many times) the whole sequence, as one would then reply the var
> changing sequence in the debugger perhaps once in the original bb, then
> once or many times again in the successor bb.

Quite the opposite: when we do jump threading, we're *bypassing* the
entire block, so in order to retain proper history we'd have to
propagate all the source-expected changes into the short-circuited
path.  To wit, we start with a computation log like this:

  jump to block A

A:
  # set foo to expr1
  # advance to line n
  # set foo to expr2
  jump to block B

B:
  # advance to line m
  # set foo to expr3

in which we can see foo bound to all 3 expressions, to a computation log
like this:

  jump to block B

B:
  # advance to line m
  # set foo to expr3

or:

  jump to block B

B:
  # set foo to expr1
  # advance to line n
  # set foo to expr2
  # advance to line m
  # set foo to expr3

which ones seems like a more faithful representation of the computation
described in the source code to you?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]