This is the mail archive of the gcc@gcc.gnu.org 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: block reordering at GIMPLE level?


> 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).

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.

Honza
> 
> Cheers,
> Roberto


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