[Bug debug/54693] VTA guality issues with loops

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-04 06:09:48 UTC ---
As a quick hack just for this testcase we might perhaps do something in jump
threading code, if we have a DEBUG stmt based on a PHI result and are splitting
it up, look if it is the last DEBUG stmt for the variable in the threaded bb
and if so, consider adding a DEBUG stmt also to the fallthru bb after the
threaded block, based on its PHI.

For the general solution, didn't give it much thought yet, but so far I was
thinking about a pass that would analyze on GIMPLE (perhaps shortly before
expansion) all DEBUG stmts and work similarly to tree-into-ssa.c algorithm
(just simplified by performing it just once, never incrementally). 
SSA_NAME_VERSION
for the debug stmt lhs decls could be some integer recorded perhaps as
gimple_uid on the debug stmts, we'd track the current definition of each debug
stmt lhs uid, and instead of inserting PHI nodes we could:
1) look for existing PHI node for the var mentioned in the debug stmt rhs,
   use that if exists
2) in bb with few incoming edges, look for existing PHI node with constant
   PHI arguments where for different current defs of some debug stmt lhs uid
   the constants have different values, like:
 <bb 7>:
   DEBUG i => D#12
   goto bb 9;
 <bb 8>:
   DEBUG i => i_17
 <bb 9>:
   z = PHI <7(7), 19(8)>

   We can then insert something like
   DEBUG i => z == 7 ? D#12 : i_17
3) otherwise punt.

Perhaps 2) would need some var-tracking changes, I'm afraid unavailability of a
VALUE for either of the branches of the COND_EXPR would reset it all.  But at
least 1) could work.