> 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?
We only create as many variables as we have statics we promote right
now.
At the RTL level, global reg has 6373 regs to allocate with promote
st
> 200.sixtrack 74 258 348.65%
I can get this down to something slightly more sane (cut down
global-alloc time by 80%) by upping the global var threshold.
The problem is that the global var threshold causes us to make all the
promoted statics touch the global var.
# .GLOBAL_VAR_2
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:
>
On Sunday 17 July 2005 19:48, Daniel Berlin wrote:
> On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> > Hi,
> >
> > There are some huge compile time regressions between 16/7 and 17/7, most
> > likely due to the IPA work from Kenny and Dan. These are the build times
> > in seconds, taken
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> Hi,
>
> There are some huge compile time regressions between 16/7 and 17/7, most
> likely due to the IPA work from Kenny and Dan. These are the build times
> in seconds, taken from Diego Novillo's nightly SPEC tester box:
As i expected,
On Sun, 2005-07-17 at 18:05 +0200, Steven Bosscher wrote:
> Hi,
>
> There are some huge compile time regressions between 16/7 and 17/7, most
> likely due to the IPA work from Kenny and Dan.
Definitely.
The peak compile time slowdown is due to the promote statics pass, which
in term causes more w
