On Thu, 6 Oct 2011, William J. Schmidt wrote:
> On Thu, 2011-10-06 at 16:16 +0200, Richard Guenther wrote:
>
> <snip>
>
> >
> > Doh, I thought you were matching gimple stmts that do the address
> > computation. But now I see you are matching the tree returned from
> > get_inner_reference. So no need to check anything for that case.
> >
> > But that keeps me wondering what you'll do if the accesses were
> > all pointer arithmetic, not arrays. Thus,
> >
> > extern void foo (int, int, int);
> >
> > void
> > f (int *p, unsigned int n)
> > {
> > foo (p[n], p[n+64], p[n+128]);
> > }
> >
> > wouldn't that have the same issue and you wouldn't handle it?
> >
> > Richard.
> >
>
> Good point. This indeed gets missed here, and that's more fuel for
> doing a generalized strength reduction along with the special cases like
> p->a[n] that are only exposed with get_inner_reference.
>
> (The pointer arithmetic cases were picked up in my earlier "big-hammer"
> approach using the aff-comb machinery, but that had too many problems in
> the end, as you know.)
Yeah, I know. It's a very tricky area ;)
> So for the long term I will look into a full strength reducer for
> non-loop code. For the short term, what do you think about keeping this
> single transformation in reassoc to make sure it gets into 4.7? I would
> plan to strip it back out and fold it into the strength reducer
> thereafter, which might or might not make 4.7 depending on my other
> responsibilities and how the 4.7 schedule goes. I haven't seen anything
> official, but I'm guessing we're getting towards the end of 4.7 stage 1?
It's a reasonable plan - you'd have to introduce a late reassoc
pass though. Can you separate out the RTL fwprop changes? So
we can iterate over the tree parts separately.
Thanks,
Richard.
