[LLVMdev] Question regarding basic-block placement optimization
Jakob Stoklund Olesen
stoklund at 2pi.dk
Tue Oct 18 16:31:39 PDT 2011
On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote:
> On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote:
> I think this should really live as a CodeGen pass. Is there any good reason to make it an IR pass?
>
> So, as it happens, I was *completely* wrong here. CodeGen correctly preserves the ordering of blocks from IR, *unless* it can do folding, etc.
That's right. However, the CFG changes quite a bit during CodeGen.
Switches can be lowered into branch trees, multiple passes can split critical edges, and then there is taildup and tailmerge.
An IR code layout algorithm simply doesn't know the final CFG.
> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the different fall-through pattern. To make matters worse, at this point we don't have the nicely analyzable 'switch' terminator (I think), and so the existing MBB placement code just bails on non-branch-exit blocks.
Those are all the wrong reasons for not doing the right thing.
Some basic blocks are glued together and must be placed next to each other. That situation can be recognized by "MBB->canFallThrough() && TII->AnalyzeBranch(MBB..)".
Treat glued-together blocks as super-blocks, and everything should be as breezy as IR.
I realize the MBB interface is not the prettiest. Suggestions for cleaning it up are very welcome.
/jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111018/f9832789/attachment.html>
More information about the llvm-dev
mailing list