Re: Combine performance regression (was: Fix PR target/18701)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jan 25, 2005 at 04:12:38PM -0700, Roger Sayle wrote:
> > I assume you're talking about combine.c:1.471:3986:
> >       /* Don't change the mode of the MEM if that would change the meaning
> >          of the address.  */
> >       if (MEM_P (SUBREG_REG (x))
> >           && (MEM_VOLATILE_P (SUBREG_REG (x))
> >               || mode_dependent_address_p (XEXP (SUBREG_REG (x), 0))))
> >         return gen_rtx_CLOBBER (mode, const0_rtx);
> >
> > (Which is either correct or likely what together with the other
> > bug confused me into thinking that something else could
> > somewhat-validly change the mode of the memory access.
> > Why else would this code care whether the address is a
> > mode_dependent_address_p?  FWIW, no, I still haven't revisited
> > this thoroughly yet.)
> >
> > How did that test go?
> 
> Completely removing the above clause from combine.c on mainline
> bootstraps all default languages and regression tests with no new
> failures on both i686-pc-linux-gnu and powerpc-unknown-linux-gnu.
> 
> I think this code, that was added by Jakub Jelinek to resolve
> PR optimization/6086, was really papering over a bug elsewhere
> in the compiler, more specifically in reload.  Given that the
> testcase that was added for that PR, g++.dg/opt/preinc1.C, now
> still passes on PPC even with the above clause removed, I'd like
> to believe that the real underlying problem has now been corrected.

I was only re-adding a hunk that was mistakenly removed by Jan
10 months before that during simplify_subregization.
Although the mode_dependent_address_p etc. check moved to simplify_subreg
(where it still is ATM), it started doing different thing than it used
to.  The fact that the testcase doesn't trigger on HEAD doesn't
imply that the underlying problem has been corrected, it would need
a new analysis what the problem actually was.

	Jakub