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

[Alexandre Oliva]

On Nov  2, 2012, Alexandre Oliva <aoliva@redhat.com> wrote:

> 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

What I wrote above was not entirely accurate.

We do bypass empty blocks, in thread_around_empty_block, but we
propagated debug stmts from their predecessors, that may actually be the
block duplicated for threading.  So, the debug stmts from the duplicated
block are entirely artificial, exclusively for purposes of SSA
resolution, while those from bypassed otherwise-empty blocks actually
tell the history of the computation.  All that said, even the latter are
useless right now, when their bindings happen to be immediately modified
by subsequent debug stmts.

Now, one of the problems with my patch was that it propagated debug
stmts over and over, when there was a long chain of empty blocks.  I'd
assumed they'd all be eliminated after the jump was redirected, but
they're only bypassed by the copy of the initial block.

Furthermore, when jump threading fails to determine the taken edge out
of e->dest, it proceeds to trying to threading through successors of
e->dest, and the current code would propagate debug stmts from e->dest
to single-pred successors at such attempt, even if no threading would
take place.

The patch below (based on a tree from before your first patch that's
already in) improves the situation: we only propagate debug stmts to the
final destination block, and only after we make sure we are performing
jump threading to that block.  Also, it refrains from propagating debug
bind stmts whose bindings are rendered inoperant by later bindings, in
the threaded blocks or at the top of the destination block.

I didn't try delaying the creation of the pointer set as you did, but
I'm now thinking using a linear on-stack vector for searches up to some
size might be even faster than creating the pointer set at the first
var.

Regstrapping on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-jump-thread-prop-less-debug-pr54693.patch
Type: text/x-diff
Size: 4641 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20121103/fdcddaf7/attachment.bin>
-------------- next part --------------


-- 
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