On Tue, Apr 05, 2011 at 02:24:55PM -0300, Alexandre Oliva wrote:
> On Apr 4, 2011, Jakub Jelinek <ja...@redhat.com> wrote:
>
> > Alternatively, perhaps all we care about is either i3, or NEXT_INSN of
> > the last debug_insn propagate_for_debug changed in an interesting way.
>
> Ideally, we'd like to identify all debug users of i2dest (or whatever
> DEF we're removing) and propagate into them, even if they are e.g. in
> different blocks or after i3.
If they are in different blocks, then either there must be some other
use of the pseudo in real code after that (but then combine won't do such
replacements), or DF would have resetted those debug_insns referencing it
(or replaced the pseudos in there with a debug temporary set before the last
real use), otherwise debug insns would change the liveness of the pseudo.
> IIRC stopping at i3 is a trade-off that avoids making the analysis more
> complex, just because we know i2dest, if removed, isn't used after i3
> any more, although it might still be used in debug insns. I don't
> recall how/when(/whether) we adjust those afterwards.
The change mode of pseudos propagation can't be a best effort, we really
must change all the pseudos (or reset debug_insns containing them),
otherwise the RTL in the insns might be invalid.
The other changes we propagate are best effort, if we don't change all,
and some pseudo remains referenced only in debug insns and not really set
in real code or used anywhere, next DF recomputation will just reset them.
Of course the less often that happens, the better.
> Anyhow, I don't quite understand what makes the retry case special.
> Each try_combine call (and its debug propagations) are supposed to be
> self-contained. If we dropped a SET, we should adjust all debug uses of
> its SET_DEST; if we didn't drop it, no adjustment is needed. It seems
> to me that extending the range might even cause us to modify
> e.g. unrelated uses of the same pseudo, no? Isn't the problem perhaps
> that we are failing to adjust some debug insns at an earlier call?
The reason why retry case is special is that without any previous
propagate_for_debug calls we know that e.g. in the change mode case,
the pseudo can't be referenced before i2 and after i3 where i2 is
the single setter of the pseudo and i3 is the single (non-debug) user.
Otherwise RTL would not be valid before combiner. But with some previous
propagate_for_debug calls in the same bb that guarantee (as the testcase
shows) is no longer true. We might have propagate_for_debug, replacing
some i2dest with i2src in between i2 and i3, then goto retry with new
i3' being somewhere before previous i3. We change mode of the pseudo
that was present in old i2src, but if we stop looking for debug insns
at i3', there might be some debug insn in between i3' and i3 that
references that pseudo.
Jakub
