Possible trip-count overflow in loop-unroll

[Michael Zolotukhin]

Hi,

This patch fixes an issue with possible integer overflow that might be caused by LoopUnroll. The problem was reported here: [1], and than it was partially solved (see [2]), but not completely.

This fix aims the following issue in LoopUnroll pass: currently LoopUnroll generates a prologue loop before the main loop body to execute first N%UnrollFactor iterations. When UnrollFactor is 2, then this loop performs a single iteration, and thus its back-edge is optimized away, and the loop actually becomes just a linear code. 

That would work fine, but it turns out that we also want to use this un-unrolled loop as a last resort if for some reason we can’t use unrolled loop. One of such reasons is possible trip-count overflow.

The attached patch makes the condition when we fully unroll the prologue more strict, and thusly fix the issue in question.

Does it look ok?



Thanks,
Michael

[1]: http://stackoverflow.com/questions/23838661/why-is-clang-optimizing-this-code-out <http://stackoverflow.com/questions/23838661/why-is-clang-optimizing-this-code-out>
[2]: http://llvm.org/bugs/show_bug.cgi?id=19846 <http://llvm.org/bugs/show_bug.cgi?id=19846>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141119/900dbe88/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LoopUnroll-tripcount-overflow.patch
Type: application/octet-stream
Size: 4376 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141119/900dbe88/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141119/900dbe88/attachment-0001.html>