On Tue, Oct 30, 2012 at 03:51:19PM +0100, Richard Biener wrote:
> + FOR_EACH_IMM_USE_STMT (stmt, imm_iter, def)
> + {
> + if (!gimple_debug_bind_p (stmt))
> + continue;
> +
> + FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
> + SET_USE (use_p, comp);
> +
> + if (!comp)
> + BREAK_FROM_IMM_USE_STMT (imm_iter);
>
> how does comp magically become NULL_TREE here?
Looks like pasto to me, from the first loop.
BTW, I'd also think that the first loop should set count = 2 if
the debug stmt already has a non-trivial expression (i.e. rhs isn't
just the SSA_NAME), to force a debug temp in that case to avoid creating too
large debug stmts.
> Btw, what's all the fuzz with IV candidates, etc? At least for non-PHIs
> I don't see why the regular release_ssa_name way of doing things does
> not work. IVOPTs is slow enough ...
Even if it is non-PHI, release_ssa_name will replace it with the definition,
and then on another release_ssa_name again and again, and finally either
be lucky enough that some SSA_NAME stays (is an IV that has been kept), but
more often you'll just reach the PHI node and end up with a long list of:
DEBUG D#7 => NULL
DEBUG D#6 => D#7
DEBUG D#5 => D#6
DEBUG D#4 => D#5
DEBUG D#3 => D#4
DEBUG D#2 => D#3
DEBUG D#1 => D#2
(the NULL because of PHI). We don't need to find optimal IV replacement,
so the code tries just a couple of them (perhaps the 64 should be a param,
and perhaps could be lower by default), it just helps if the expression is
smaller (smaller debug info), and if it contains as few SSA_NAMEs as
possible (then it is more likely it will actually be useful).
Jakub
