------- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 -------
> dorit,
> i am having trouble exactly reproducing this example because you did not
> give the svn revision and so all of the numbers are a little bit
> different.
it's revision 127623
> However, I am going to submit a patch which improves the dump
> information a lot for these passes and we should talk about it after we
> can get on the same page.
I applied your patch, and I'll send you the dump shorlty.
> However, from looking at your posting, there are some issues that you
> may want to look at before we talk:
> The reaching defs problem makes a scan for all of the defs in the blocks
> in the region. Once all of the defs are found, they are sorted where
> the primary key is the regno.
> The id's (DF_REF_ID) are then assigned based on this sorting. The
> reaching defs problem actually depends on all of the defs for a regno to
> be contigious.
> The DF_REF_IDs are not stable between calls to df_set_blocks and any def
> outside of the region has an undefined DF_REF_ID.
> In your posting you have:
> > Below is the output of df_ref_debug for adef in each iteration of the loop
> > in
> > latch_dominating_def:
> > d40 reg 187 bb 3 insn 255 flag 0x0 type 0x0 loc 0xf7da4608(0xf7d9a4e0)
> > chain { }
> > d93 reg 187 bb 2 insn 40 flag 0x0 type 0x0 loc 0xf7d89cc8(0xf7d9a4e0) chain
> > { }
> The number after the first "d" is the DF_REF_ID. Note that they are not
> contiguous.
> Given the sorting that occurred, they must be contiguous. I assume from this
> that
> someone is holding on to old id's. This is not correct.
> If you are going to play the game with df_set_blocks, you are allowed to hold
> onto a
> def, but not the DF_REF_ID, you cannot look at the DF_REF_ID for a def
> that is not in the blocks set by df_set_blocks.
are you saying it's safer not to call df_set_blocks in iv_analysis_loop_init?
(iv-analysis still fails when I do that, but maybe that in turn requires other
changes?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
