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_insn_refs_record's handling of global_regs[]


From: "Seongbae Park (박성배, 朴成培)" <seongbae.park@gmail.com>
Date: Tue, 16 Oct 2007 21:53:37 -0700

Annyoung haseyo, Park-sanseng-nim,

> loop-invariant.cc uses ud-chain.
> So if there's something wrong with the chain,
> it could go nuts.
> Can you send me the rtl dump of loop2_invariant pass ?

I have found the problem, and yes it has to do with the ud chains.

Because global registers are only marked via df_invalidated_by_call,
they get the DF_REF_MAY_CLOBBER flag.

This flag causes the dataflow problem solver to not add the global
register definitions to the generator set.  Specifically I am
talking about the code in df_rd_bb_local_compute_process_def(), it
says:

	if (!(DF_REF_FLAGS (def)
	      & (DF_REF_MUST_CLOBBER | DF_REF_MAY_CLOBBER)))
	  bitmap_set_bit (bb_info->gen, DF_REF_ID (def));

Global registers don't get clobbered by calls, they are potentially
set as a side effect of calling them.  And they are set to valid
values we might actually depend upon as inputs later.

I tried a potential fix, which is to change df_insn_refs_record(),
such that it handles global registers instead like this:

	if (global_regs[i])
	  df_ref_record (dflow, regno_reg_rtx[i], &regno_reg_rtx[i],
	                 bb, insn, DF_REF_REG_DEF, 0, true);

and this made the illegal loop-invariant transformation no longer
occur in my test case.


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