As per the title, fix the rotation by not truncating the shift amount to the bit width.
Add a unit test to check that 1 << 33 produces 2.
There are two problems with the rotl() proposed by this patch:
Updated the code to use 'urem' to get the remainder, rather than calling getZExtValue.
Should the APInt rotateAmt need to have the same bitwidth as the APInt the rotl is being called on? urem and a few other methods need that.
Should the APInt rotateAmt need to have the same bitwidth as the APInt the rotl is being called on?
I don't see any reason to add that restriction. (Please add a test for this.)
Please add a testcase for a very large rotate amount (greater than 2^64). Please add testcases for rotating an integer whose bit-width is not a power of two.
"APInt(rotBitWidth, BitWidth)" could be zero. (For example, APInt(32, 1).rotl(APInt(1, 1)). Please add this as a testcase.)
Please factor out the common code from rotl and rotr into a helper function. Maybe also add a comment describing why it's implemented in this particular way, since it's a bit subtle.