For any unpaired muls, we accumulate them as an input to the reduction. Check the type of the mul and perform a sext if the existing accumlator input type is not the same.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
Could you describe the complete flow here? If getAccumulator() returns a value, I think I see how it works; the type of that value is the type of the final accumulator, and you need to sign-extend multiplies to match that type. If getAccumulator() returns null, I don't see how this is supposed to work; it looks like the code arbitrarily decides the accumulator should be 32 bits.
Comment Actions
Bah! You're right, it doesn't make sense and there wasn't a test for it... I'm now querying the root for the type and creating the right zero accumulator input if needed. Added more 64-bit tests too.