[patch] Stay in cfglayout mode until after cse2

Steven Bosscher stevenb.gcc@gmail.com
Mon Mar 26 11:13:00 GMT 2007

On 3/26/07, Paolo Bonzini <paolo.bonzini@lu.unisi.ch> wrote:
> >>                /* Otherwise we have some return, switch or computed
> >>                   jump.  In the 99% case, there should not have been a
> >>                   fallthru edge.  */
> >> +              if (NEXT_INSN (bb_end_insn) == 0
> >> +                  || !BARRIER_P (NEXT_INSN (bb_end_insn)))
> >> +                emit_barrier_after (bb_end_insn);
> >>               continue;
> >
> > This is wrong. You would emit the barrier as a non-insn after the end
> > of the basic block, which you can't do in cfglayout mode. If the
> > barrier would go anywhere, it would be in bb->il.rtl->footer.  But in
> > this case, emiting a barrier is just wrong. Why did you need this?
> I don't really recall this exactly, it will take some more
> investigation.  It doesn't seem to be so wrong to force the
> presence of a barrier when going *out* of cfglayout mode if
> there's no fallthrough edge.

But cfg_layout_finalize already forces a barrier after non-fallthrough
edges, so you still shouldn't need this.

Also, afaics you add the barrier while still in cfglayout mode, and
you shouldn't have to do that.

>  The presence of barriers is
> probably the biggest difference between cfglayout and cfgrtl
> mode, isn't it?

I wouldn't say that.  It's a difference, but it is only a consequence
of other differences.

> delete_insn_and_edges amounts basically to delete_insn +
> purge_dead_edges.  In the case of a conditional jump having
> having been simplfied to (set (pc) (label_ref FOO)), p_d_e
> will see two edges and no jump -- it will then keep the old
> fallthru edge, which is wrong as it should keep the *other* edge.

Then the proper thing to do would be to update the CFG in place, i.e.
the place that turns the conditional jump into an unconditional one.
You would only have to remove the redundant edge, and put the
EDGE_FALLTHRU flag on the other edge. (For transformations of
!any_condjump to unconditional jumps, you'd probably have to do
something similar.  I don't know if this ever happens, though.)

> It might be that this is a latent bug in delete_insn_and_edges.

I don't know.  If you don't tell it which edge to keep, it'll keep the
wrong edge, I suppose.

> > Note that unconditional jumns may be omited in cfglayout mode.
> Exactly.  After purge_dead_edges, in fact, I have delete_insn
> to delete the now-unconditional jump.

Good :-)

> > I don't know if this will make us miss
> > opportunities to combine insns with unconditional jumps, if some silly
> > target wants to be able to do that...
> No, that should not be a problem.

Also good :-)

Thanks for working on this,


More information about the Gcc-patches mailing list