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.
joey on Dec 14 2016, 3:33 AM.Authored by
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.
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.