[Mono-dev] mono / llvm inlining situations (or failures thereof)

[Jonathan Shore]

Hi Rodrigo,

I have played with the MONO_INLINELIMIT env variable (just discovered in the mono code a couple of days ago).  It solved some of my other inlining issues.   The AggressiveInlining option should be helpful for methods in 4.5 (I'm still on 4.0), though I don't believe the attribute can be used on properties, even though they are effectively methods (or am I wrong here).

I noticed the code in method-to-ir.c, the other day re: excluding code that needs a class constructor to be run.   I am not clear on what this means exactly.   Are you referring to:

classes with static constructors
classes with non-empty constructors
something else? 

You mentioned "we don't inline methods that call other methods" and suggested might be the case in my code.   I am simply indexing the get method in:

public override double this[int i]
{
	get { return _data[i]; }
	set { _data[i]  = value; }
}

I thought that since this is an override, though on a leaf / sealed class, perhaps mono could not handle this case.   Not sure where indexing on this property would hit the "call another method" case.

If I understand this better, I can investigate / suggest some new feature re: inlining.

Thanks
Jonathan


On Jul 16, 2012, at 12:20 PM, Rodrigo Kumpera wrote:

> Hi Jonathan,
> 
> There are a few factors that affect inlining. 
> 
> We don't inline more than 10 levels deep, but I doubt this is your problem.
> We don't inline synchronized methods, methods that belong to MarshalByRef classes or method that do exception handlibg. Not your case, probably.
> We only inline methods smaller than 20bytes of IL. It might be your case. You can control this with the MONO_INLINELIMIT env var or use the AgressiveInlining compiler hint.
> We don't inline calls to classes that need their class constructor to be ran. Might be your case.
> We don't do inlining when generics are involved. Doesn't look to be your case;
> And, finally, we don't inline methods that call other methods (including constructors).
> 
> The last restriction does look to be your issue. We do it due to a pair of issues, first because it produces broken stacktraces
> and because it breaks calls that check caller assembly. Both can be fixed if mono had support for inlining maps.
> 
> My suggestion is that you play with MONO_INLINELIMIT and AgressiveInlining. This can be reported as a feature request.
> I would love to see this done.
> 
> Regards,
> Rodrigo
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120716/841b30af/attachment-0001.html>