Possible trip-count overflow in loop-unroll

[Sanjay Patel]

Hi Michael,

I have a similar patch to fix this here:
http://reviews.llvm.org/D6200

Based on this newer bug report:
http://llvm.org/bugs/show_bug.cgi?id=21409

How does your change to the prologue check affect the transform? Can you
post example code with and without that change? I minimized the test case
in my patch, so it might be easier to explain using that as the example
code.


On Wed, Nov 19, 2014 at 6:36 PM, Michael Zolotukhin <mzolotukhin at apple.com>
wrote:

> 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
> [2]: http://llvm.org/bugs/show_bug.cgi?id=19846
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141120/4fa34f81/attachment.html>