This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [RFC] loop index promotion pass
On Wed, May 20, 2009 at 04:38:23PM +0200, Richard Guenther wrote:
> On Wed, May 20, 2009 at 4:23 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> > - The loop indices weren't recognized as IVs because of the type
> > ?conversions done to them when being incremented and as part of the
> > ?loop exit testing. ?(Possibly just the incrementing; I don't remember
> > ?that clearly and don't know the loop optimization bits well enough.)
> > ?Therefore, simple_iv &co was not an option.
>
> It would be nice to have a smaller testcase that shows this.
Well, it's not particularly small, but you can tweak the testcase I
posted in my initial mail about the pass:
------------------------------------------------------------------------
#ifndef PROMOTE
#define INDEX_TYPE unsigned short
#else
#define INDEX_TYPE unsigned int
#endif
void
frob (unsigned char *in, unsigned char *out)
{
unsigned short h = 640, w = 480;
INDEX_TYPE i, j;
for (i = 1; i < (h - 1); i++)
for (j = 1; j < (w - 1); j++)
{
unsigned int c = (i * w) + j;
unsigned short b = (in[c - w -1]
+ in[c - w]
+ in[c - w + 1]
+ in[c - 1]
+ in[c]
+ in[c + 1]
+ in[c + w + 1]
+ in[c + w]
+ in[c + w - 1]);
*out++ = b;
}
}
------------------------------------------------------------------------
Compile with and without -DPROMOTE and compare dump files; you should
notice a lot of missed opportunities when compiling without -DPROMOTE.
At the very least, I know simple_iv returns false on the loop indices
above. analyze_scalar_evolution_in_loop does not return bare CHRECs for
the appropriate IVs; it returns upcasted ones, which confuse simple_iv.
> Can you produce compile-time numbers to show how much overhead the
> pass adds?
I can do that. Will report back later.
-Nathan