Finally tying up loose ends here.
The problem is quite simple:
If we have pattern (x >> start) & (1 << nbits) - 1,
and then truncate the result, that truncation will be propagated upwards,
into the and. And that isn't currently handled.
I'm only fixing pattern a here,
the same fix will be needed for patterns b/c too.
I *think* this isn't missing any extra legality checks,
since we only look past truncations. Similary, i don't think
we can get any other truncation there other than i64->i32.