[Mono-dev] Ping on nternal call builders

[Massimiliano Mantione]

On Wed, 2008-07-30 at 09:19 +0200, Kornél Pál wrote:
> I believe that there is no use to force managed-to-managed wrappers to 
> be inlined. I just would like to elminiate the code that prevents them 
> being inlined. If inlining is considered carefully (this should be the 
> case) then I don't think that forcing inlining is a good idea. Just 
> short managed-to-managed wrappers that call no methods and throw no 
> exceptions (in other words those that would be inlined if they weren't 
> wrappers) should be inlined.
> 
> I still didn't find out how to implement this. Could someone please help me?

Unfortunately, the checks for inline are a bit complex.

There are three main kinds of reasons why we do not inline a
method:
- The method is too long, so we believe that inlining it would
  be bad (the concept of "too long" has been tuned looking at
  benchmark results, so any change should be validated in the
  same way... the typical benchmarks were an mcs bootstrap,
  scimark and some XML related thing I don't remember).
- Then, several methods don't get inlined only because with
  the current jit the performance would be worse, even if
  "common sense" would suggest otherwise (more on that later).
- Finally, several programs failed with inline enabled because
  this altered stack traces, and this induced a bunch of other
  limitations.
  I remember when I coded them I introduced the INLINE_FAILURE
  macro, so if you grep for it in mini.c you'll see them.

About the second point: when we inline, we create one local
for every parameter of the inlined method.
This creates register pressure, and the current register
alocator simply cannot handle that.
Those extra locals must be eliminated using DEADCE.
However, we only perform local DEADCE by default (the global
one needs SSA and we cannot afford it), and this is the main
reason why we do not inline methods that contain branches:
the added locals would not be optimized out.
Typically they would induce spilling, which would make the
inline counterproductive.

And it can get worse than that: see here for the fugly hack
we had to put in place to actually make inlining of simple
methods (as simple as property getters!) worth doing:
http://tirania.org/blog/archive/2006/Jan-24.html

This is on inlining in general:
http://primates.ximian.com/~massi/blog/archive/2006/Mar-27.html

And this is about the call stack behavior:
http://primates.ximian.com/~massi/blog/archive/2006/Apr-13.html

The good news is that the current commit of the linear IR work
is the first step in getting a better JIT infrastructure so
that we can handle these things properly.

Hope this helps understanding why things are not so easy...

Ciao,
  Massi