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 5:15 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> 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.

Yes, but that is as far as I remember from my attempt to analyze
that testcase because it cannot prove that there is no overflow.
Which is why I questioned the validity of your transformation ;)
(I couldn't think of any way to prove non-wrapping for the above loop
either...)

Another possibility I see is that forwprop should remove the
promotion in the exit test.  fold_widened_comparison needs
to see that the sign-change involved is harmless though
(it's not an equality comparison).  And forwprop needs to accept
the folded result as simplification.

Richard.


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