Re: alias slowdown?

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2006-11-20 at 21:34 -0500, Daniel Berlin wrote:
> On 11/20/06, Andrew MacLeod <amacleod@redhat.com> wrote:
> > On Sun, 2006-11-19 at 20:16 -0500, Daniel Berlin wrote:
> > > >
> > > > In the meantime, is there a simple way to disable this "more correct"
> > > > mechanism so I can get my timings?
> > >
> > > You'll get testsuite failures if you disable it because it fixes a
> > > bunch of bugs.
> > >
> > > You can always disable all of PTA, but i would not recommend it.
> > >
> >
> > I don't care about testsuite failures, Im trying to time the new
> > out-of-ssa relative to the old one in compile time. I've already done
> > all the testsuite work. I just want to compare before and after times
> > and releative to total compile time. Disabling it works for me if it can
> > get me moving. Is there a simple way to do this?
> 
> But then you are comparing oranges and apples. It's useless to compare
> something if you are turning off a part of the compiler that is on by
> default, and provides us significantly different IR.

no Im not. If I compare the same source base with old outofssa with new
outofssa, it doesnt matter. Im compare the differences in my code, which
is what I care about.  Sure the IL is different, but its the same for
both compilations I am comparing. I can compare which is better.

> 
> >Weren't there any
> > performance checks done before checking the code in?
> Of course i did performance checks.
> It causes no regressions in timing on even huge C++ test cases like tramp3d-v4.

I use 4 primary testcases... cpgram.ii for the last 2-3 years at least.
all.i and bug2.ii which are quite recent, and all the gcc .i files.   2
of my 4 standard cases basically don't work.
> 
> Why would I test codes from random PR's that nobody reports regular
> results on, instead
> of using large cases that people like Richard Guenther track
> compilation and runtime performance of, on a web page, making
> comparison easy?

I dont consider them random, I consider them standard performance
testcases for me personally to check because they have demonstrated
significant slowdowns that we have had to make changes to many parts of
the compiler in order to fix them (or currently are fixing). 

Perhaps we need a webpage with multiple compile times being tracked, or
simply a standard compile time regression suite from existing PRs to
avoid this kind of thing in the future. 

> > These are pretty severe regressions.
> There was a time when PTA took > 800 seconds on this testcase and over
> 2 gig of memory.
> 
And I wouldn't expect it to be the default at that point either.

> Also, this change fixed 3 P1 blocker regressions in 4.2.  I warned
> when i checked it in that it may cause problems.  I performance tested
> it on all of our release criteria, and then some.  What more do you
> want me to have done, other than start pulling codes from random bug
> reports that don't even compile anymore (see below)?

Then we ought to consider adding a couple of these to the standard
performance criteria then. I would expect these will show up as
regressions at some point against 4.2

> 
> If you want to fix those some other way, you are welcome to back out
> the whole patch.
> 

no thanks :-)

> That said, the current issue seems simple, and i'm working as fast as
> i can. I already have something that makes _all.i take 4 seconds total
> for PTA, and am now working on cpgram.

cool :-)  You didn't tell me you were actively working on it, all I knew
was you gave me a patch that made no effective difference on either
testcase for me, and I still had to kill the process.

 A significant amount of time has been spent in the past to make these
test cases run faster, we ought not lose track of them. They all exposed
issues with multiple passes.


> 
> >
> >
> > > With the attached patch, it should take less than 60 seconds per PTA
> > > run for all.i (i have no copy of cplusplus_grammar.i, and it's not
> > > clear where to get it).
> >
> > Its originally from 15855. (compiled with -O2 -fpermissive)
> 
> It doesn't even compile for me, even with -fpermissive.
> I had to get a preprocessed version from someone who had gotten it
> working before with our current tree.

Yeah, I don't know. I've had a copy for a couple of years now.  I think
there might have been a newer version in a PR somewhere.  I will attach
what I use.

 
> >
> > 60 seconds on what kind of machine?  I'm trying all.i with this patch
> > now, but it hasn't finished compiling after 13 minutes... (it use to
> > take 5).
> 
> my dual core macbook pro with 2 gig ram.
> 
> > cplusplus_grammer.ii runs in 44 seconds on the branch I cut in the
> > summer. this patch doesn't make it very fast either.  My machine is a
> > 3.0 Ghz P4 with 1GB of ram, and it appears to be just swapping its guts
> > out.   I killed it after 20 minutes, even with this patch I
> 
> BTW, I don't even get to the first call to compute_points_to_set in 44
> seconds on mainline, so, uh.

A no checking compiler? ...   anyway, 44 seconds overall for me. (I
think its actually 55 on the p4 , 44 seconds is on my 1.8 ghz Pentium-M
laptop)

Andrew

Attachment: cpgram.ii.bz2
Description: application/bzip