Investigate IV opts

ivopts is generally a win but has a fair number of cases where turning it off significantly improves performance. We should investigate whether we can improve the ivopts heuristics in order to make it a more consistent win.

Specifically, if a loop iterates over N arrays, there are two extremes:

  1) have N separate induction variables, one for each array,
  2) have an induction variable for one array A and N-1 loop invariants that hold the difference between the other arrays and A

All other things being equal, ivopts tends to prefer (2). This makes sense on x86, which has reg+reg+offset addressing, but (1) is usually better on ARM. There are two reasons for this:

  a) it allows us to use post-index addressing
  b) although core ARM loads and stores supported reg+reg addressing, NEON loads and stores do not. So (2) tends to introduce extra additions or subtractions into the loop

The biggest benefit of this work would be seen on vectorised loops that operate on several arrays. One example is colour-space conversion.

See:
 http://gcc.gnu.org/ml/gcc/2011-07/msg00050.html

and:
 http://lists.linaro.org/pipermail/linaro-toolchain/2011-September/001589.html