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.
