[Mono-dev] Ping on nternal call builders
massi at ximian.com
Wed Jul 30 04:57:00 EDT 2008
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
- 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
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
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:
This is on inlining in general:
And this is about the call stack behavior:
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...
More information about the Mono-devel-list