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 _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list