This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: EON regression due to pass ordering problem (PRtree-optimize/24653)
- From: Jeffrey A Law <law at redhat dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org, evandro dot menezes at amd dot com, dnovillo at redhat dot com, rth at redhat dot com
- Date: Thu, 03 Nov 2005 10:09:03 -0700
- Subject: Re: EON regression due to pass ordering problem (PRtree-optimize/24653)
- References: <20051103133120.GS30564@kam.mff.cuni.cz> <84fc9c000511030546s628ada31x4399438b433005d7@mail.gmail.com>
- Reply-to: law at redhat dot com
On Thu, 2005-11-03 at 14:46 +0100, Richard Guenther wrote:
> On 11/3/05, Jan Hubicka <jh@suse.cz> wrote:
> > Hi,
> > we have over 10% regression in Eon that I think it typical enought for
> > C++ so we should solve it for 4.1. The problem is caused by missed SRA
> > oppurtunity on startPoint variable appearing in many of it's internal
> > functions. The missed SRA (we did SRA it in 4.0) is caused by fact that
> > originally the code after inlining functions that manipulate with it is:
> >
> > this = &startPoint;
> > this->e[0] = code;
> >
> > and so on. Until dom1 pass we still maintain pointer "this" so the
> > startPoint must live in memory. DCE properly transforms it into:
> >
> > this = &startPoint;
> > startPoint.e[0] = code;
>
> http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01702.html
>
> teaches forwprop to do this transformation (I guess there really are multiple
> uses of 'this'). I wonder why DCE does such transformation, and why
> DCE does not help the tramp3d cases I invented the forwprop change for.
I believe this is already queued for 4.2 :-)
jeff