Investigate IV opts

Registered by Michael Hope on 2011-09-07

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

Blueprint information

Status:
Not started
Approver:
Michael Hope
Priority:
Medium
Drafter:
Richard Sandiford
Direction:
Approved
Assignee:
None
Definition:
Discussion
Series goal:
Accepted for 4.6
Implementation:
Informational Informational
Milestone target:
milestone icon backlog

Related branches

Sprints

Whiteboard

[2013-05-28 matthew-gretton-dann] Moved to Jira: http://cards.linaro.org/browse/TCWG-130

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.