This is a work in progress and is to aid discussion in the loop opt working group.
An opportunity for peeling exists for loops like the following:
unsigned Sum = 0;
for (unsigned I = 0; I < 999; ++I)
Sum += g();
In this situation, the initial value results in an identity operation on the first iteration of the loop.
This loop could be peeled to avoid this operation:
unsigned Sum = g();
for (unsigned I = 0; I < 998; ++I)
Sum += g();
This idiom frequently occurs in the form of summing up the values in an array. It can also occur with *=, &&= and ||=.
The number of tests requiring changes here illustrates that this is a common idiom. There may be more tests that need updating
but since this is currently for discussion purposes, this task has not been completed. These tests were mostly altered by dis-allowing peeling or changing the initial value to 1 from 0, making it not an identity operation.
There are several questions about the role of peeling in the llvm opt pipeline but the main one raised by this sample follows: This will likely be a relatively minor small improvement and it may interfere with other optimizations so is it worth pursuing?
For example, there is an attempt to not interfere with vectorization in the code as it exists. This heuristic needs improvement as the above sample, for example, will not peel if the upper bound is 10,000 as it may fail the heuristic on some hardware.
Consider using doxygen comments (starting with ///). Doxygen code samples are indented by 4 spaces.
Could you explicitly list all the cases that should be handled. E.g.