This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compile time increases on Diego's SPEC box
- From: Richard Henderson <rth at redhat dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Steven Bosscher <stevenb at suse dot de>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc at gcc dot gnu dot org, dnovillo at redhat dot com
- Date: Sun, 17 Jul 2005 11:32:44 -0700
- Subject: Re: Compile time increases on Diego's SPEC box
- References: <200507171805.42425.stevenb@suse.de> <1121622525.1157.11.camel@linux.site>
On Sun, Jul 17, 2005 at 01:48:44PM -0400, Daniel Berlin wrote:
> As i expected, the sixtrack slowdown is entirely in global-alloc, in
> daten.f
>
> with -fno-tree-promote-statics
> global alloc : 0.23 ( 4%) usr 0.00 ( 0%) sys 0.24 ( 3%)
> wall 448 kB ( 3%) ggc
>
> without:
>
> global alloc : 375.96 (83%) usr 5.00 (62%) sys 453.83 (82%)
> wall 10714 kB ( 5%) ggc
>
>
> Cute, no?
>
> It just has a lot more variables to deal with now that they aren't
> statics that live in memory (a lot of things now get SRA'd that didn't
> before, etc).
Would you care to characterize the number of extra variables created
at the tree level and the number of extra pseudos created at the rtl
level? I could see that there's room to be lazy and create hundreds
of extra unnecessary variables that will exacerbate this problem.
For instance, if there's a global variable X that gets promoted to a
local, and a function FOO that kills X, one could do
x1_1 = X;
// use x1_1
foo ();
x2_2 = X;
// use x2_2
or
x_1 = X;
// use x_1
foo ();
x_2 = X;
// x_2
wherein the difference is that the first case uses two variables for
the different live ranges, and the second uses only one.
r~