A well behaved loop is normally of the form: for a = b + 5;
Because the increment is unitary and constant, it's very easy to see that, if both a and b are bigger than MAX, this loop will never access memory outside the allocated range.
Non-normalized loops
A non-normalized loop may begin at different indexes, increment by not-unitary amounts and have exit conditions complicated to define. Such loops are hard to optimize, vectorize and even traverse, especially if functions are executed on any part of the loop conditions. A simple example, where it doesn't start at the beginning and increments by more than one: // Example 1 for a = b + 5;
A more complicated example, with an additional exit condition: // Example 2 for a = b + 5;
Loops can also have non-predictable behavior during compilation time, where the exit condition depends on the contents of the data being modified: // Example 3 for a = b + 5;
Or even dynamic calculations by means of function calls: // Example 4 for ; i < max; i+=increment ) a = b + 5;
Reverse loops are also very simple, and can be easily normalized: // Example 5 for a = b + 5;
Converting to a normalized loop
If the non-normalized doesn't have dynamic behaviour, it's normally very easy to transform it to a normalized one. For instance, the first example above can easily be converted to: // Example 1 -> normalized for a = b + 5;
While the third example can be partially normalized to allow some parallelization, but still lack the ability to know the loop span, making it harder to vectorize by using multi-media hardware. Starting at 7 is not so much of a problem, as long as the increment is regular, preferably one. When multiple statements inside the loop use the index, some private temporary variables may be created to cope with the different iteration paces. The reverse loop is also easy to normalize: // Example 5 -> normalized for a = b + 5;
Note that the access is still backwards. In this case, it makes no sense to leave it backwards, but where dependences exist, caution must be taken to revert the access as well, as it could disrupt the order of assignments.
The Example 4 above makes it impossible to predict anything from that loop. Unless the functions themselves are trivial, there is no way to know where the loop will start, stop and how much it'll increment each iteration. Those loops are not only hard to parallelize, but they also perform horribly. Each iteration, the loop will evaluate two functions and increment'''). Even if the functions are inlined, the condition becomes too complex to be worth optimizing. The programmer should take extra care not to create those loops unless strictly necessary. Another danger of such loops appear if the evaluation depends on the data being modified. For instance, a normal error when using iterators is to remove items from a list while modifying it, or relying on sizes that are not true any more.
