cmplwi vs cmpwi is a type tell
Compares are gossip. The one a branch leans on will tell you, if you bother to listen, exactly how its operand was typed. Picture a narrow signed parameter, sixteen bits wide, getting tested against 100. It shows up as cmpwi — but only after extsh has reached in and copied the sign bit across everything above it:
extsh r0,r3 # sign-extend narrow signed value
cmpwi r0,100 # signed compare
bne- skip
bl trigger
Retype that same value as unsigned and the story shifts. The compare grows an l and turns into cmplwi (logical, that is), while the instruction feeding it stops caring about sign and just rakes the top bits down to zero:
clrlwi r0,r3,16 # zero-extend narrow unsigned value
cmplwi r0,100 # unsigned compare
bne- skip
bl trigger
After that it comes down to the one letter and whichever extend set things up. clrlwi clearing the high bits points at an unsigned value; extsh or extsb smearing the sign downward points at a signed one. And clrlwi is generous — the shift it uses spells out the original width. So a cmplwi in your target leaves nothing ambiguous: the source was unsigned, width and all.
Your task
act is a function. The starter below declares the parameter as s16 x, which produces extsh + cmpwi (the signed compare). Change the parameter type so the comparison emits cmplwi instead — the target uses the logical (unsigned) compare at the same 16-bit width.