This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] [RFC] loop index promotion pass
On Fri, Apr 24, 2009 at 11:42:19AM +0200, Richard Guenther wrote:
> On Thu, Apr 23, 2009 at 6:17 PM, Nathan Froyd <email@example.com> wrote:
> > The pass is placed as early as possible in the pipeline so that as many
> > optimizations as possible see the promoted indices.
> > Bootstrapped on x86_64-unknown-linux-gnu. Comments welcome.
> I wonder if on no-undefined-overflow branch we can simply avoid
> the promotion/demotion (by teaching fold to recognize the
> (short)((int)x +/nv (int)y) pattern and fold it to x + y).
Something along those lines would be nice. (Although the actual thing
to recognize would be (short)((unsigned short)x +/nv (unsigned short)
> Or maybe I am missing what is exactly confusing the compiler here?
> Is it that c is unsigned int? Or is it that the induction variable
> arithmetic and loop exist tests are done in int?
IIRC, the IV canonicalization passes get confused by the casts on the IV
arithmetic, not the casts. You're not doing the arithmetic on the
actual index, you're doing arithmetic on a differently-typed value and
then stuffing that back into the loop index. (This issue affects other
things, like computing loop trip counts and so forth, not just IV
canonicalization.) If signed arithmetic was represented in the IR as
actual signed arithmetic and not convert-to-unsigned-and-back, then IV
canonicalization might do the right thing for free.
> Other than that, why did you not implement this in the
> induction variable canonicalization pass (thus, simply create
> an alternative induction variable there)?
Because I did not see how to make the loop optimizer bits handle the
casts correctly. I agree that this would be a more elegant solution,
but it will have to wait for somebody smarter than myself to implement
it. (Or until I get a chance to sit down and receive a serious tutorial
from the loop optimizer folks...)