http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-17 10:44:23 UTC --- I am slowly starting to look into fortran issues now. For years it was non-issue since we had the non-one-decl-per-function problem. This is finally solved One additional problem is that we often hit large-stack frame limits because the fortran i/o drops large datastructure on stack. Consequently any functions that do i/o (for debug purposes, for example) are not inlined into functions that doesn't. We will need to relax this. - Consider heuristics to mark functions as inline in the front end: - If it has many arguments (argument processing has a lot of effect) - If it uses assumed-shape arrays (setting up that array descriptor may take a lot of time - Mark everything as inline I briefly discussed option of marking everything as inline on IRC for 4.6.x series but it did not go well with Richard. Observation is that dominating coding style in fortran is to not care that much about code size if perfomrance improve and inlining do help here. In longer term it would be cool if inliner was able to work out as much as possible himself w/o frontend help. The first item you mention is something backend can do at its own (and it already knows how to benefit many arguments, but it proably does not do it enough to make difference for fortran). I am just about commit patch that makes backend by hair more sensitive on this. The second item is interesting - it would be cool if backend was able to work out that the code is supposed to simplify after inlining. Either by itself or by frontend hint. Can you provide me very simple testcase for that I can look into how it looks like in backend? Perhaps some kind of frontend hinting would work well here. Honza