When the target kept its separate compare
Now and then the retail object got built with the peephole pass switched off over some region, so the dot-merge from last lesson simply didn't run. What you find instead is a plain, undotted instruction trailed by an explicit cmpwi ...,0. No amount of C rewriting brings that back. The only lever is the pragma the original author reached for.
#pragma peephole off
/* ...function... */
#pragma peephole reset
Wrap the body in that pragma and the exact code that merged a moment ago now keeps its compare standing on its own.
clrlwi r0, r3, 24 # mask — NOT the dot form
cmpwi r0, 0 # explicit compare the peephole would have absorbed
beq- L
add r3, r4, r0
Put the two outputs next to each other and the dot-merge is the whole difference.
# peephole ON (lesson 3) # peephole OFF (this lesson)
clrlwi. r0, r3, 24 clrlwi r0, r3, 24
cmpwi r0, 0
beq- L beq- L
The . disappears and a full cmpwi walks back in. That's the textbook fingerprint of peephole off. Out in real decomp work you fence a function, or a stretch of several, and every off you write gets a matching reset.
Both the starter and the solution already carry the #pragma peephole off / reset lines, so all you owe is the body. The same pair was applied to the reference target, which is how it ended up un-merged in the first place.
Your task
Fill in the body of pick2 (same logic as pick) so that, with peephole disabled, you match the un-merged clrlwi + cmpwi + beq- sequence.