On Jun 3, 2011, Eric Botcazou <ebotca...@adacore.com> wrote: > Does the same logic need to be replicated in all passes that do? On > the other hand, these passes call into DF when they remove insns, so > DF is a central place here.
I went over (again?) a number of passes that call delete_insn directly or indirectly. The problem is that, at that point, it's not possible to tell whether: - equivalent DEFs are going to be re-emitted at the same place (say, a split), so debug insns are to be left alone, - whether they're being re-emitted elsewhere (say a move), so *some* debug insns may have to be adjusted - whether DEFs are really being removed, in which case debug temps may have to be emitted; and the uses, adjusted; and other reaching defs also followed by binding of the same debug temps - whether many chained insns are being deleted (say an entire BB, or part of a BB found to be shared between multiple BBs), in which case debug insns may have to be left alone or adjusted depending on the CFG adjustments to be made later Given this analysis, I'm still of the opinion that passes that remove insns that may be used by debug insns ought to decide on their own how to make the adjustments (or not), as they currently do, but that we should have better shared infrastructure to propagate defs-to-be-removed, which is currently done in an ad hoc manner in several passes. -- 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
