This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] tree-cfg.c: Speed up cleanup_tree_cfg().
Hello,
> > > > while (something_changed)
> > > > {
> > > > something_changed = cleanup_control_flow ();
> > > > something_changed |= delete_unreachable_blocks ();
> > > > something_changed |= thread_jumps ();
> > > > retval |= something_changed;
> > > > }
> > > >
> > > > Kazu Hirata
> > > >
> > > > 2004-10-01 Kazu Hirata <kazu@cs.umass.edu>
> > > >
> > > > * tree-cfg.c (cleanup_tree_cfg): Pull a call to
> > > > cleanup_control_flow() out of the while loop.
> > > Seems reasonable to me.
> >
> > in fact I think whole loop can be removed, since thread_jumps
> > cannot create new unreachable blocks the way it is written
> > now (it removes the blocks directly in the case they become
> > unreachable).
>
> I have not checked if thread_jumps() leaves unreachable blocks, but it
> does sometimes leave further transformation opportunities for itself.
> Consider the following example.
>
> <L1>
> if (COND) goto L2; goto L3;
>
> <L2>:;
>
> <L3>:;
>
> redirect_edge_and_branch() replaces the COND_EXPR with an
> unconditional jump like so
>
> <L1>
> goto L3;
>
> <L2>:;
>
> <L3>:;
>
> Note that L1 was not a forwarder block, but now it is. The old L1 may
> have blocked previous attempts to thread through L1. Admittedly, this
> situation is rare and occurs only a few times in GCC itself (because
> it implies that we have a completely meaningless "if" statement).
ummm... OK, forgot on this case.
Still it should be harmless to move delete_unreachable_blocks before
the call. thread_jumps does not leave unreachable blocks (well, I hope;
if it does, it is a bug).
Zdenek