Re: Fix df-core to not look for df info on notes

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> On 5/13/06, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> >(With the fwprop patch I get two extra failures which are caused by
> >bugs in fwprop that were hidden with the previous df-core.c diff, see
> >http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00727.html.  It seems
> >that fwprop introduces a new JUMP_INSN that sets nothing but (pc), and
> >somehow that insn isn't getting DF info attached to it.  Working on it,
> >but it's irrelevant for this df-core.c patch...)
> 
> It turns out that this happens because flow_loops_find changes the
> cfg, which is incredibly annoying in any case, and in particular here
> because it doesn't update dataflow information.  So in
> fwprop.c:fwprop_init() we have:
> 
> static void
> fwprop_init (void)
> {
>  num_changes = 0;
>  df = df_init (DF_SUBREGS | DF_EQUIV_NOTES);
>  df_chain_add_problem (df, DF_UD_CHAIN);
>  df_analyze (df);
>  df_dump (df, dump_file);
> 
>  if (flag_rerun_cse_after_loop && (flag_unroll_loops || flag_peel_loops))
>    {
>      calculate_dominance_info (CDI_DOMINATORS);
>      flow_loops_find (&loops);
>    }
> }
> 
> After df_analyze we assume that we have dataflow info on all
> instructions.  But with flag_unroll_loops or flag_peel_loops,
> flow_loops_find is called, it changes the CFG, and new insns appear
> that df_analyze hasn't analyzed.  This causes two test suite failures.
>
> Zdenek, why does flow_loops_find have to modify the CFG?

in order to avoid having loops with multiple latch edges.

> It has
> caused some trouble before (for the morpho target, which has to do its
> own loop discovery in the machine reorg pass because of this).  Is
> there some way to avoid this?

It would be possible to avoid resolving loops with multiple latch edges,
but the changes needed would be fairly significant (there is a lot of
code in cfgloop* that rely on this -- it makes a lot of things simpler
to do; and in fact even struct loop would need to be changed, as
currently it cannot represent such loops).

In this particular case, the trivial solution is to move flow_loops_find call
to the beginning of the fwprop_init.

In the morpho case, a simple possibility would be to add a flag to
flow_loops_find to ignore loops with multiple latch edges (I am not sure
whether/how many opportunities it would miss, then).

Zdenek