Possible trip-count overflow in loop-unroll

[Arnold Schwaighofer]

This LGTM.






Thanks Michael!






If the loop count is not constant we can't tell statically whether it will overflow hence we will need the remainder loop in case we do - so we can't 'unroll' the remainder loop:






  bool UnrollPrologue = (Count == 2 && isa<ConstantInt>(TripCount))






And your are bailing out if you can statically tell that we are going to overflow:






  // If BECount is INT_MAX, we can't compute trip-count without overflow.


  if (BECount->isAllOnesValue())


    return false;










On 11/19/14, Michael Zolotukhin 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?


>