This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Memory footprint/compile time explosion caused by the tree inliner
Joe Buck wrote:
According to Vlad, there is no hope, the scheduler is at least O(n^2).
On Fri, Apr 18, 2003 at 10:49:51AM -0400, Geert Bosch wrote:
Why can't we just insert arbitrary scheduling barriers in very large
functions and schedule the pieces independently? We could relate the
maximum size of a piece to expected execution frequency, so that we
work harder to optimize loops than other code.
We pretty much have to do something like that; there are a lot of
processor simulator codes that have huge functions that are essentially a
straight line. Toon, you're the expert, but I understand that this is
really common in scientific Fortran codes.
Well, certainly there are Fortran codes that have 1000's of lines per
subroutine (our own code is an example of that coding style).
The question is, however, whether lines-of-code-per-function is the
problem - does the scheduler really consider a complete subroutine for
optimization ? Fortran codes (if they're not automatically generated)
are normally full of loops, which partition the code in scheduling
regions naturally, I'd assume.
--
Toon Moene - mailto:toon at moene dot indiv dot nluug dot nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)