They are most definitely supposed to be uint32.
The code I copy pasted it from has them as a struct containing 1 field; num:uint32. After deciding it would be nicer for the issue to have a and b be uint32, I aperantly also immediately forgot about that.
I just tested, and it is also present with just a straight up uint32 (technically an alias). I updated the code to reflect the fact that its an alias.
fun fact, embeded in a struct the first example is slower than a straight up uint32 alias, but for the second example the embeded version is faster than a straight up uint32. Even though they both show a benefit.
There could be some analysis on if the branch is likely to be taken. IIRC this is already done in one way or another (like optimizing for the branch predictor?).
Then you could make a check that does this if it is determined the branch is highly unlikely, and a subset of another branch, and no returns in between that could be taken.
I dont know if this is something you want to do in the gc, where compilation performance is also important, that is up to you. But I think that you could make programs faster on average using this optimization at a certain threshold.