[PATCH] D125774: [InstCombine] fold float trunc into exact itofp for small constants

[Allen zhong via Phabricator via llvm-commits]

Allen added a comment.

In D125774#3584831 <https://reviews.llvm.org/D125774#3584831>, @nikic wrote:

> I'm not strongly opposed to adding some basic IV reasoning to computeKnownBits(), but the implementation needs to be much more careful. I think there are //at least// three bugs here (missing check for predicate, no check whether this is a loop exit or continue condition, no reasoning about how the start value range relates to the end value). This requires much more extensive testing (and those tests should be simpler, not involving float operations).

Probably ill-considered, I think a basic IV start with **positive A**, end with **positive B**，and whatever his predicate of the icmp, the IV is always in the range [A, B], so if we can know that the most significant n bits of both A and B are 0, the most significant n bits of the currently IV is also necessarily 0, that's why I associate the start value with the end value.

> If you want to add this, you'd probably want to start over with just handling a canonical IV (step 1 incrementing IV with start smaller and end and ult or ne condition), and expand from there.
>
> Generally, the utility that handles this kind of simplification based on IV ranges is SimplifyIndVars -- that one is based on the full power of SCEV, and will be able to deal with non-trivial recurrences. Extending it to handle this case is probably the most correct approach. Maybe there are complications with looking through float operations there though.

Thanks @nikic very much for pointing out the derection to resolve this issue, I'll take a look at the SimplifyIndVars. Since I have poor experience with SCEV, it would be nice if you could let me know which API functions may require attention.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125774/new/

https://reviews.llvm.org/D125774