This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR54693] loss of debug info in jump threading and loop ivopts
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 02 Nov 2012 15:56:35 -0200
- Subject: Re: [PR54693] loss of debug info in jump threading and loop ivopts
- References: <orr4olzqwe.fsf@livre.localdomain> <20121101092756.GF1891@tucnak.redhat.com>
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