This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix VTA updating in the combiner (PR debug/48343)
On Apr 4, 2011, Jakub Jelinek <jakub@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.
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.
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?
--
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