The loop bound given by ScalarEvolution is given as a signed value, thus it can wrap around if the value was a big unsigned one. To handle this we can promote the type to the next bigger one iff the code generation can handle the next bigger type. This also refactors the process of bailing out in the ScopInfo as we now have two reasons to do so (to many parameters in the alias checks and types to big for the code generation). This patches removes two __very old__ XFAIL tests and replaces them by new ones that check for the problem earlier (in the ScopInfo). One of the new tests is taken from the bug report linked below. This fixes http://llvm.org/PR17187
This patch makes me nervous because I don't see why it is obviously safe to always promote to the next size without changing semantics. For example, with this loop:
for (uint8_t i = 1; i != 0; ++i) A[i] += 1;
If we blindly promote to uint16_t in the c source then we have definitely changed the trip count.
We handle this case by bailing out in ScopDetection. I think that is a safe first way to fix the bug.