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.)
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?
