[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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