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
