This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]