Originally these changes were part of https://reviews.llvm.org/D65276. Decided to have a separate review for changes aimed at improving evaluateAtIteration. The problem is that evaluateAtIteration can produce incorrect result under some circumstances. For example for evaluation 32-bit nested recurrence of level 2 we need to carry all calculations in 33-bits. This requirement applies to input iteration expression as well. Thus if the input iteration expression is 32-bit and we can't prove it doesn't overflow then evaluateAtIteration will give incorrect result.
Please note that we can't just discard all cases when number of bits in iteration expression is less than required. One common case which we need to support is constant. It's known that constant never overflows thus it's safe to extend it to required number of bits. There are over cases where we can prove that expression doesn't overflow.
Thanks
Evgeniy
Ok, I'm definitely not getting something here.
trunc(zext(y, N), M) is always equal to y when N > M and M is width of y. The zext adds zeros, then the truncate removes them.
Additionally, the comments above in the intro to this function seem to directly contradict the newly added code.
There's no test case provided to show a difference in output.
Given all of the above, I'm definitely unconvinced of this patch.