This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Handle ADDR_EXPR in SCEV
On Wed, 17 Feb 2010, Richard Guenther wrote:
> Otherwise the patch looks good (the above is just to make
> the analysis not allocate memory unnecessarily). I'll test
> its effect on SPEC2006.
There was a ~10% code-size and ~3% performance regression on bwaves. I've
investigated it, and posting my analysis for the record.
The problems I've found are:
1) DOM does not copy-propagate stride into increments of induction variables
(a side effect of tree-ssa-dom.c:2004, a fix for PR23281); however, this is
fixed by RTL loop invariant motion.
2) Type of some induction variables changes from int to sizetype, increasing
their size. This probably has a minor impact.
3) I think the biggest problem is that for references in nested loops
(a[i][j]) we create an IV (&a + i*stride) that is live in the outer loop.
In bwaves, there are deeply nested loops with references to multiple arrays, so
updating such IVs on stack has impact on code size and performance.