<div dir="ltr">MBBs aren't superblocks, they generally represent a single IR block. The MBB representation allowance for multiple terminators is so that a two-way conditional branch can be emitted. There, you generally need two instructions: a conditional branch, followed by an unconditional branch. <div><br></div><div>There is also allowance for control flow out of the middle of the MachineBasicBlock, in a couple of limited circumstances: a CALL instruction may throw to an EHPad successor (lowered from the "invoke" IR instruction), and an INLINEASM_BR instruction (lowered from an IR "callbr" instruction) may jump to one of its indirect successors. In both of those cases, the instruction which was a terminator at the IR level, is not at the MachineInstruction level. As the IR block is lowered to a MBB, the IR terminator is the last "logical" thing that happens in the MBB, but e.g. the CALL instruction is not the literal end of the block. All of the return handling for the call sequence (e.g. tearing down the stack frame, copying registers, loading values, etc) all happens in the same basic block as the CALL, despite that the CALL may in fact throw out to an exception-handling basic-block, rather than continue the rest of its block. Similarly for INLINEASM_BR.<div><div><br></div><div><div>If you want to get a concept of what's going on internally, the "-print-after-all" flag to llc (or -mllvm -print-after-all in clang) is a great way to see the transformation of the code as it goes through every pass, from the high-level IR transformations, down to the final assembly.</div><div><br><div><div><div></div></div></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 11, 2020 at 2:41 PM Chris Sears via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators<span class="gmail_default" style="font-size:small">; t</span>he MIPS backend also marks conditional branches as terminators. The MachineBasicBlock <span class="gmail_default" style="font-size:small">then </span>has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB.<br><br>So it seems to me that an MBB is a kind of superblock, single entrance and multiple side exits. <span class="gmail_default" style="font-size:small">There are also</span> TailDuplication and BranchFolding passes. While these two are technically not part of the superblock definition, they are usually part of a superblock implementation because you want   a superblock <span class="gmail_default" style="font-size:small">to be </span>as<span class="gmail_default" style="font-size:small"> big as</span> possible.<div><br></div><div><div class="gmail_default" style="font-size:small">Of course, you could make a big superblock in the CFG and then tile it down into basic MBBs. But the only reason  that I can think of for that would be codegen simplicity and with GlobalISel, I would think that would no longer be the case.</div><br>A<span class="gmail_default" style="font-size:small">nyways, a</span>m I getting this right? If so, is there any way to control the creation of th<span class="gmail_default" style="font-size:small">ese</span> superblock<span class="gmail_default" style="font-size:small">s</span>, that is, which basic blocks from the CFG go into a given MBB?<br><br>I'm still in the MC layer, so I really don't know where in the MI layer this <span class="gmail_default" style="font-size:small">sort of </span>tiling of the CFG is done. (In a full blown superblock formation that tiling would be a profile driven decision for finding the hot trace.)<br><br>It's always good to just look at things. So I want to just display some MBBs for some code for some backend at preEmit and just look at what they look like. Any suggestions for that will be appreciated.<br><br>thanks,<br><br>Chris<br><br>BTW, this is at the MI-MC interface. The IR BasicBlock is <span class="gmail_default" style="font-size:small">a </span>completely different<span class="gmail_default" style="font-size:small"> issue.</span></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>