------- Comment #94 from dberlin at gcc dot gnu dot org 2009-02-14 23:06
-------
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
One of the reasons LCM in RTL is so slow is because it uses a crappy
iteration order.
With the right iteration order, it should be fast enough to turn it
back on and remove the address calculations in these testcases.
If it was block based, it would have been converted to use the DF
solver and gotten this automatically, but because it's edge based,
pretty much nobody has touched it since it was created :)
Even adding qsorts in the right place that sort the worklists into the
right order on each iteration would probably help orders of magnitude
here (though moving to the two worklist solver that DF now uses would
be even better).
On Sat, Feb 14, 2009 at 4:58 PM, lucier at math dot purdue dot edu
<gcc-bugzi...@gcc.gnu.org> wrote:
>
>
> ------- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58
> -------
> Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines
>
> I instrumented the compiler and looked how many nodes were in each
> loop processed by LICM for the Gambit runtime and compiler.
>
> For generated code, except for the "loop" that contained the entire
> function, the greatest number of nodes was 30. (Because computed
> gotos are used in the code that checks for heap and stack overflows
> after allocations and for waiting interrupts, it's hard to go long in
> Scheme code without hitting the "big loop".) For hand-written code,
> the greatest number of nodes in a loop was 123.
>
> When bootstrapping gcc with --enable-languages=c, the largest number
> of nodes in a loop was 803, and there were 12 loops detected that had
> over 500 nodes. 548 loops had 100 nodes or greater. (This is a
> bootstrap, so some files were compiled twice with the instrumented
> compiler.)
>
> So perhaps an -O1 default for LICM of 100 nodes is reasonable, or
> perhaps one might up it to 1000 just to catch everything "reasonable".
>
> Brad
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
