This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]