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], &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.

Reply via email to