[PR debug/46240] don't introduce debug bind stmts at merge edges

[Alexandre Oliva]

A throwing call must be at the end of a BB, right?  Well, then...  what
if we need to insert a debug bind stmt right after the call, because the
result of the call is assigned to a user variable?

If the fallthrough edge has a single pred, as usual, no problem,
inserting on the edge amounts to inserting in the beginning of the
subsequent block.  However, if there's more than one predecessor, we
can't insert the debug bind stmt at all, because inserting at the edge
would amount to creating a new BB just for this one debug stmt, which
would change the CFG and trigger undesirable codegen differences.

We used to guard against fallthrough BBs without a single predecessor,
but now that I see it's possible, I've reworked the code to deal with
this situation.  We still don't emit the debug bind stmt, but that's
because we don't have to: if we're getting to a confluence point that
joins the path with the call, that set a user variable, and another in
which the assignment wasn't present, there is going to be a PHI node
there, and there will be a debug bind stmt corresponding to that PHI
node, so the debug bind stmt we'd emit would be redundant anyway.  So,
we can just refrain from emitting it, without loss of debug info.  Yay!

Here's the patch.  Regstrapped on x86_64&32-linux-gnu.  Ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-skip-insert-bind-after-call-pr46240.patch
Type: text/x-diff
Size: 5297 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110117/1c5cdadc/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