When does MWCC pick which?
The table form and the compare chain are both in MWCC's toolbox, and the choice is mechanical: it depends on how many cases there are and how densely they pack. Two rules of thumb that this compiler follows:
- Dense and few → compare chain. A run of
0..5 (six consecutive cases) still bisects with cmpwi / beq- / bge-. The crossover on this toolchain is seven consecutive cases: 0..6 and up switch to the table. Concretely: 0..5 (six cases) stays a compare chain; 0..6 (seven cases) is the first to cross into table form; lesson 1's 0..7 (eight cases) sits comfortably above the threshold. The rule is "at least seven," not "more than eight."
- Sparse → compare chain, always. Cases like
2, 20, 200, 1000 are far apart. A table indexed by x would need 1000 entries (mostly default) — far too big — so MWCC bisects them no matter how many there are:
cmpwi r3, 200 # probe the middle case value
beq- .case200
bge- .hi # x > 200 -> search the upper half
cmpwi r3, 20
beq- .case20
bge- .default
cmpwi r3, 2
beq- .case2
b .default
.hi:
cmpwi r3, 1000
beq- .case1000
b .default
...
.case2: li r3, 1 # each case body is the same tiny li/blr...
blr # ...only the dispatch above differs from the table form
So when you're matching a switch, count the cases and check their spread first. A lone cmplwi + bctr means dense-and-many (write consecutive cases). A staircase of cmpwi/beq- against scattered constants means the original values were sparse — and the constants in the asm tell you exactly which case labels to write.
Your task
Write route(int x): a sparse switch on x. Read the cmpwi probe values from the assembly above to recover which case labels to write, and read the li r3, N in each arm to recover the return value. Four scattered cases stays a compare chain.