------- Comment #4 from zadeck at naturalbridge dot com 2007-08-30 14:43
-------
Subject: Re: failing rtl iv analysis (maybe due
to df)
dorit at gcc dot gnu dot org wrote:
> ------- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 -------
> (In reply to comment #2)
>
>> I suspect this might be due to not updating the rd information after
>> unrolling.
>> Can you check if
>> analyze_insns_in_loop() (which calls df_analyze()) is being called just
>> before
>> the problematic unrolling ?
>>
>
> it looks like it's called just before the unroller actually transforms
> somthing, but not before the (failing) analysis. But when I add a call to it
> in
> decide_peel_completely the analysis still fails.
>
>
>
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.
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.
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.
Kenny
Index: df-core.c
===================================================================
--- df-core.c (revision 127917)
+++ df-core.c (working copy)
@@ -1761,6 +1761,7 @@ df_print_regset (FILE *file, bitmap r)
/* Dump dataflow info. */
+
void
df_dump (FILE *file)
{
@@ -1778,6 +1779,33 @@ df_dump (FILE *file)
}
+/* Dump dataflow info for df->blocks_to_analyze. */
+
+void
+df_dump_region (FILE *file)
+{
+ if (df->blocks_to_analyze)
+ {
+ bitmap_iterator bi;
+ unsigned int bb_index;
+
+ fprintf (file, "\n\nstarting region dump\n");
+ df_dump_start (file);
+
+ EXECUTE_IF_SET_IN_BITMAP (df->blocks_to_analyze, 0, bb_index, bi)
+ {
+ basic_block bb = BASIC_BLOCK (bb_index);
+
+ df_print_bb_index (bb, file);
+ df_dump_top (bb, file);
+ df_dump_bottom (bb, file);
+ }
+ fprintf (file, "\n");
+ }
+ else df_dump (file);
+}
+
+
/* Dump the introductory information for each problem defined. */
void
Index: df.h
===================================================================
--- df.h (revision 127917)
+++ df.h (working copy)
@@ -836,6 +836,7 @@ extern bool df_reg_used (rtx, rtx);
extern void df_worklist_dataflow (struct dataflow *,bitmap, int *, int);
extern void df_print_regset (FILE *file, bitmap r);
extern void df_dump (FILE *);
+extern void df_dump_region (FILE *);
extern void df_dump_start (FILE *);
extern void df_dump_top (basic_block, FILE *);
extern void df_dump_bottom (basic_block, FILE *);
Index: loop-invariant.c
===================================================================
--- loop-invariant.c (revision 127917)
+++ loop-invariant.c (working copy)
@@ -644,6 +644,7 @@ find_defs (struct loop *loop, basic_bloc
if (dump_file)
{
+ df_dump_region (dump_file);
fprintf (dump_file, "*****starting processing of loop ******\n");
print_rtl_with_bb (dump_file, get_insns ());
fprintf (dump_file, "*****ending processing of loop ******\n");
Index: loop-iv.c
===================================================================
--- loop-iv.c (revision 127917)
+++ loop-iv.c (working copy)
@@ -280,7 +280,7 @@ iv_analysis_loop_init (struct loop *loop
df_set_blocks (blocks);
df_analyze ();
if (dump_file)
- df_dump (dump_file);
+ df_dump_region (dump_file);
check_iv_ref_table_size ();
BITMAP_FREE (blocks);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
