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
- Repository
- rL LLVM
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.