This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] tree-cfg.c: Speed up cleanup_tree_cfg().


Hi Zdenek,

> > >   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).

Actually, I once wrote a patch to completely flatten the loop, but its
description was too long.  So I am thinking about speeding up
cleanup_tree_cfg() little by little so that everybody can follow
"correctness proofs" as I submit patches.

Kazu Hirata


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]