This is the mail archive of the
mailing list for the GCC project.
Re: Fix df-core to not look for df info on notes
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Kenneth Zadeck <zadeck at naturalbridge dot com>, Daniel Berlin <dberlin at dberlin dot org>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Sun, 14 May 2006 00:02:27 +0200
- Subject: Re: Fix df-core to not look for df info on notes
- References: <firstname.lastname@example.org> <email@example.com>
> On 5/13/06, Steven Bosscher <firstname.lastname@example.org> 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).