This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: DF_DU_CHAIN | DF_UD_CHAIN flags in new-ra
- From: Michael Matz <matz at suse dot de>
- To: "Mukta Punjani, Noida" <muktap at noida dot hcltech dot com>
- Cc: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
- Date: Tue, 16 Sep 2003 14:31:19 +0200 (CEST)
- Subject: RE: DF_DU_CHAIN | DF_UD_CHAIN flags in new-ra
Hi,
On Tue, 16 Sep 2003, Mukta Punjani, Noida wrote:
> d1 def r161
> u11 use r161
> u12 use r161
> ...
> d2 def r161
> u21 use r161
> In this case, use-def chain for r161 will be consisting of {d1,d2}. In case
The _reg_-def chain will contain both defs. But the def-use chains will
look like:
[d1] --> {u11,u12}
[d2] --> {u21}
> insn corresponding to u12 is modified, it will try to unlink reference from
> both the defs d1 and d2.
It shouldn't do that. Let's say u12 will be deleted, then df_ref_remove()
will be called on that u12. That in turn will call:
df_use_unlink (u12);
df_ref_unlink (&df->insns[DF_REF_INSN_UID (ref)].uses, u12);
The last df_ref_unlink call will succeed, because the insn of u12 needs to
contain the ref u12. And df_use_unlink will do:
forall (defs d in use-def-chain[u12])
df_ref_unlink (u12 from def-use-chain[d])
So df_ref_unlink is only called on those chains, where the use-def chain
of u12 pointed to a def. I.e. if the use-def chain of u12 contains d,
then the def-use chain of d has to contain u12. And this is the
consistency what the abort is testing.
Somehow this invariant was mixed up. Try to find what use is trying to be
deleted, and why it is tried to be deleted from a def-use chain which
didn't contain it.
Ciao,
Michael.