This is the mail archive of the
mailing list for the GCC project.
Re: [patch] fix pr22550
On Tue, 2005-07-26 at 09:44 -0400, Diego Novillo wrote:
> On Tue, Jul 26, 2005 at 09:32:09AM -0400, Andrew Pinski wrote:
> > > Well, it looks like we need to return to the old cleanup cycle.
> > > In some cases (loop-5.c at -O3) we need 3 rounds of:
> > >
> > > cleanup_control_flow()
> > > delete_unreachable_blocks()
> > > cleanup_forwarder_blocks()
> > > merge_seq_blocks()
> > Can't we just stop merge_seq_blocks from doing CCP's job?
> Well, we need to stop it from doing CCP because of the SSA update
> issue (wasn't that patch applied already?).
> However, it's not just CCP. Any kind of propagation done in
> merge_seq_blocks() that may fold a predicate can trigger this.
> Though it would fix this particular case, it would not fix
> something like:
> # BLOCK 1
> x_3 = PHI <y_2>
> # BLOCK 2
> if (y_2 == x_3)
> After merge_seq_blocks() that if() at block 2 will be folded.
I think the big question we need to answer is whether or not
merging blocks with these kind of degenerate PHIs is really
worth the effort.
I'm pretty sure later optimizers would catch and eliminate
these degenerate PHIs (we'd of course need to verify that).
So the question becomes whether or not removing them in the CFG
cleanup code rather than in the regular optimizers provides
us with some benefit -- compile-time speedup, or possibly
secondary optimization opportunities that would be missed if
we killed these degenerate PHIs and merged blocks in a
later optimization pass.
> I forgot about the third alternative, which is to just make
> optimizers handle no-op conditionals (as in James' original
Which is also a possibility. The downside is whatever compensation
code we need would probably be needed in a variety of optimizers.
This may open us up to a long term maintenance headache.