Possible trip-count overflow in loop-unroll

Arnold Schwaighofer aschwaighofer at apple.com
Thu Nov 20 09:22:03 PST 2014


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?


> 




More information about the llvm-commits mailing list