I came across some bugs in the mips rules while reviewing the typed aux conversion for those rules.
Constant shifts require 0-31 as the shift amount. Rules like this:
(SLL x (MOVWconst [c])) => (SLLconst x [c])
Might violate that invariant. Might just need &31 in a few places.
We should check all the other uses of constant shifts to make sure they obey the invariant listed in the opcode definition. Maybe even define a new aux type range0to31 or something to help with enforcement (which the check pass can check).
To be clear, I don't think there is an actual code generation bug.
The docs for SRAconst, for example, just say "arg0 >> auxInt, signed". But I don't think that's what it actually does, at least if you interpret >> as a Go shift. I think they do arg0 >> (auxint%32). In which case, it should say that. But better would be to say that the constant shifts must have an arg 0-31. That would ensure a canonical representation for constant shifts, which might help a bit during CSE, and more generally just be clearer to understand.
That's what we do on other archs, e.g. for amd64/SHLQconst: arg0 << auxint, shift amount 0-63