This chapter outlines a two-pass algorithm for partitioning a sequence of machine instructions into Basic Blocks (BB). Pass 1 identifies block headers and exit points, while pass 2 allots each of the BBs so found a unique, arbitrary number. Numbering in sequential order is a plausible convention. By that convention, the physically first instruction will have BB number 1 associated with it. Zero or more subsequent instructions may have the same associated BB number, until a new BB starts, or the end of I is reached. If a new BB starts, its BB number will be 1 higher than the previous.

Input is a sequential stream of instructions I plus the index of the start instruction start. Output is an ordered sequence of BB numbers, one associated with each instruction in I.

The instruction indexed start effectively is the destination of an invisible branch, executed by the Operating System.

Partitioning instructions into Basic Blocks (BB) is a useful aid in numerous optimizations. Some optimizations are performed solely within one BB; these are called local optimizations. Others are performed across all BBs of a complete function; those are called global optimizations, simply because they go beyond the locality of one BB.

The essence of a BB, a sequence of 1 or more instructions with a unique entry point and a single exit point, is the absence of any control flow within the block. Hence it is easy within a BB to answer questions of the kind: is the subexpression x identical to the other x in this BB? Or: Since there are two assignments to object x in this BB, and no intermediate use, can the first assignment of x simply be eliminated?

See also the section on Control Flow Graphs (cfg).

A Basic Block is a the sequence of (1 or more )consecutive instructions, starting with a unique entry instruction (header, aka leader), ending with an exit instruction that leads to another BB or ends the whole program (e.g. a Halt instruction). Note that it is possible to have single-instruction BBs. Entry instructions are explicitly created by (being the destination of) branch and call destinations. They are also created by fall-though in the case of conditional branches. Exit instructions are created explicitly by branches and calls; or implicitly by the next instruction being a new entry (aka leader or header).

Instructions that end a BB include: branches, conditional branches, indexed branches (for branch tables, Case Statements), function calls, procedure calls, exceptions, halt, function return, and procedure return. The destination of a branch is called a leader, as that instruction leads a new BB. Also, the first instruction of the main function is a leader; it will be initiated by the surrounding system (jumped to by OS code). Note that statement labels, procedure entry and similar instructions do not create leaders (or end a BB). Instead, it is the respective call instruction for a procedure entry (penter) instruction and the branch for a label that creates the leaders. In fact, if a penter instruction exists in I that is never made a leader, the corresponding penter instruction and hence the complete associated procedure body are unreachable code.

At the end of the BB analysis each instruction in I must be either reached, unreachable, leader, or unreachable leader. The purpose of unreachable leaders is explained below. Unreachable code can be eliminated from I.

What are unreachable leaders for? The successor of an unconditional branch implicitly creates a new BB entry at the next instruction. However, this new BB is only live if another instruction transfers control to the place after the unconditional branch. If not, the complete BB is unreachable. To keep the counting of BBs intact, it is convenient to mark such places as unreachable leaders.

The algorithm to identify BBs is a simple two-pass process. Pass 1 identifies all reachable instructions in I and all leaders. Pass 2 allots bb numbers with each BB in sequential order from 1 to n.

1.) Initialize all instructions are unreachable. 2.) Mark instruction I[ start ] a leader; leader implies reachable. 3.) For each instruction I[ pc ] in I perform the following analysis:

• Branch: mark the branch destination a leader; note that successor is NOT automatically made a leader
• Conditional branch: mark the branch destination and next instruction I[ pc+1 ] each a leader
• Function or procedure call: mark the callee and next instruction I[ pc+1 ] each a leader; note that the second action allows us to treat return operations as dead-ends, like a halt, trap, exception, or an abort.
• Indexed branch: mark each destination in the branch table a leader
• Function or procedure return: mark as an exit point
• Halt, exception, trap, abort: mark as exit point

Any other instruction: mark the successor of any non-control-flow instruction as reached. Rationale: If control ever reaches the current instruction at pc, then during execution there will be a fall-through, reaching the next one at pc+1. On the other hand, if the header is never reached, it will never be labeled a leader, and hence all code in that BB is unreachable, and the unreachable code is detectable.

Process in sequence all instructions pc in I, starting at 0. See, whether instruction I[ pc ] is reachable, a leader, or an unreachable leader. Check the opcode of each instruction I[ pc ]. For any operation I[ pc ].opcode do:

• For a function or procedure entry: increment bb and mark instruction I[ pc ].BB = bb
• For a branch, halt, exception, trap, abort, function return or a procedure return: if instruction I[ pc+1 ] is reached, make it a leader; else if it is already a leader, no-op; else if it is unreachable, make it an unreachable leader. If in the end I[ pc ] is a leader or an unreachable leader, then increment bb and mark instruction I[ pc ].BB = bb
• For a any other instruction: if I[ pc ].class is leader or unreachable leader, increment bb and mark instruction I[ pc ].BB = bb

After checking the opcode of instruction I[ pc ], set that instruction's BB number to bb. Note that some instructions may be live, because they are referenced solely by instructions that themselves reside in unreachable code. Hence unreachable code removal is an iterative process that must proceed until no further instructions can be removable. This should be done, if you are not building a cfg, as the latter trivially detects unreachable code.

The unreachable code at instruction 4 is caused by the Then Clause being terminated via a Return Statement. The explicit transfer of control to then End If will therefore never happen. Similarly, the abort at instruction 10 in Example 1, meant to catch a fall-through to the function's end will never happen; the function return will prevent that.

Note that here we see an example, in which unreachable code (quad 10) is solely reached by an instruction in unreachable code, quad 4. Pass 1 of the BB algorithm will mark quad 10 erroneously a leader, and hence reached. The future unreachable code removal and subsequent Basic Block Analysis will render quad 10 also unreachable.

Since the penter instruction at pc = 4 for procedure proc2 is unreachable, the whole procedure, quads 4 through quad 9, is superfluous. Note that the Basic Block Analysis applied here does detect this.