This is the mail archive of the 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] Stay in cfglayout mode until after cse2

On 3/26/07, Paolo Bonzini <> 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,


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