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] Fix PR46556 (poor address generation)


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.


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