Hi, I know little about CLI, but assuming that your backend is nonstandard enought so it seems to make sense to replace the RTL bits I guess it would make sense to make the bb-reorder run on GIMPLE level too, while keeping bb-reorder on RTL level for common compilation path. This is example of pass that has very little dependency on the particular IL so our CFG manipualtion abstraction can be probably extended rather easilly to make it pracically IL independent.
The reason why it is run late is that the RTL backend modify CFG enough to make this important. CLI might have the same property. What you might want to consider is to simply port our CFG code to CLI IL representation, whatever it is and share the pass. The tracer pass, very similar to bb-rorder in nature, has been ported to work on gimple, but the implementation is not in mainline yet. You might want to take a look at changes neccesary as bb-reorder should be about the same (minus the SSA updating since you probably want to bb-reroder after leaving SSA form) Honza > > Hello, > > While working on our CLI port, I realized that we were missing, among > others, the block reordering pass. This is because we emit CLI code > before the RTL passes are reached. > Looking at the backend optimizations, it is clear that some modify the > CFG. But my understanding is that loop optimizations and unrolling are > also being moved to GIMPLE. I do not know about others. > > Could it be that sometime all the optimizations that modify the CFG are > run on GIMPLE? > Is there any plan/interest in having a block layout pass running at > GIMPLE level? > > Cheers, > > -- > Erven.
