From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
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], ®no_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.