This function will calculate an upper bound for the loop trip count. The returned value does not have to be exact: the loop may iterate fewer times in all circumstances.
Motivation:
This loop came from a customer code:
struct S { unsigned X; int Y; }; int fred(int A, int B, struct S *P) { int C = A - 1; while ((B & 3) != 0) { P->X = C * 128; P->Y = 0; P++; B++; } return 0; }
Regardless of what B is, the loop will execute at most 4 times, however the upper bound returned from getSmallConstantMaxTripCount is CouldNotCompute. This loop ends up getting interleaved by the loop vectorizer, which causes a needless code growth.
The maximum can actually be computed from the predicated backedge taken count, and patch uses that information to calculate another estimate of the upper bound.
As is, this patch will break a few lit tests. Right now I just want to get initial feedback on whether this is the right approach.
The comment is backwards: the important thing is that actual trip count may be larger than the upper bound.