This is an archive of the discontinued LLVM Phabricator instance.

don't unroll loops with zero trip count; fix for PR21409
AbandonedPublic

Authored by spatel on Nov 10 2014, 1:47 PM.

Details

Summary

In PR21409 ( http://llvm.org/bugs/show_bug.cgi?id=21409 ), the loop unroller tries to transform a loop with a backedge count of i32 4294967295. Adding 1 to that causes an overflow of the SCEV value for the trip count. This patch adds a check to prevent unrolling that type of loop.

Diff Detail

Event Timeline

spatel updated this revision to Diff 16007.Nov 10 2014, 1:47 PM
spatel retitled this revision from to don't unroll loops with zero trip count; fix for PR21409.
spatel updated this object.
spatel edited the test plan for this revision. (Show Details)
spatel added reviewers: hfinkel, atrick, majnemer.
spatel added a subscriber: Unknown Object (MLST).
hfinkel edited edge metadata.Nov 10 2014, 2:10 PM

So this solves the constant-trip-count case, do we have the same problem at runtime if the backedge count dynamically takes the maximum value?

This change actually is in the runtime unroller...why we're getting here for a compile-time constant loop is another bug?

In the compile-time unroller, we do this check:

TripCount = SE->getSmallConstantTripCount(L, ExitingBlock);

And getSmallConstantTripCount() has this:

// In case of integer overflow, this returns 0, which is correct.
return ((unsigned)ExitConst->getZExtValue()) + 1;
In D6200#5, @spatel wrote:

This change actually is in the runtime unroller...why we're getting here for a compile-time constant loop is another bug?

The runtime unroller also does partial unrolling of large-trip-count loops. So we're probably in the right place (UINT_MAX is certainly above the full-unrolling limit).