Re: block reordering at GIMPLE level?

[Roberto COSTA <roberto dot costa at st dot com>]

Jan Hubicka wrote:
> > Hello,
> > CLI back-end uses GIMPLE representation (to be more precise, a subset of 
> > GIMPLE, the code undergoes a CLI-specific GIMPLE lowering at the end of 
> > middle-end passes) and just emits bytecode in a CLI-specific assembler 
> > generation pass.
> > Because of that, we (I mean CLI back-end project) wouldn't even have to 
> > redefine our CFG, we already use CFG for GIMPLE.
> > I think it's interesting for us to check whether the existing RTL 
> > reordering pass may be reused with little or no modification and, if 
> > not, to see if it can be made it more IL independent.
>
> The BB reordering pass got some IL specific parts for hot/cold function
> splitting, but the rest should just work fine with little changes and
> cleanups. (the main algorithm is basically duplicating blocks via
> already virtualized interface and constructing new ordering via bb->aux
> pointers.  Then it rely on RTL specific cfglayout code to do the actual
> reordering that you can just do on gimple with little effort since the
> GIMPLE BBs are easilly reorderable).

Good!

> Does CLI's conditional jumps have one destination and falltrhough or two
> destinations?  If you have no natural fallthrough edges, reordering
> blocks is easy.  If you do have fallthrough after conditional jump, you
> will need to immitate cfglayout code inserting unconditional jumps into
> edges.

CLI conditionals (except the switch statement) have one destination and 
fall-through.
In the current CLI emission code, an unconditional jump is generated for 
the ELSE operand of a COND_EXPR statement, unless the target basic block 
is the one that follows in the current layout.

Cheers,
Roberto