Memory footprint/compile time explosion caused by the tree inliner

[Toon Moene]

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@moene.indiv.nluug.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)