[Mono-dev] mono / llvm inlining situations (or failures thereof)
Rodrigo Kumpera
kumpera at gmail.com
Mon Jul 16 18:11:12 UTC 2012
On Mon, Jul 16, 2012 at 2:45 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:
> 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).
>
You can use it on the 4.0 profile if you wish to, just use the literal
value and cast it to the enum. I believe .NET will ignore such directive.
The directive can be added to getter/setter in the same way custom
attributes are.
> 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:
>
>
> 1. classes with static constructors
> 2. classes with non-empty constructors
> 3. something else?
>
>
A static constructor that has not run yet. Eg:
class Foo {
static object bar = new object ();
}
>
> 1.
>
>
> 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.
>
This should probably inline fine. Can you provide a small and complete
sample where this does happen? Your problem sounds really odd.
> If I understand this better, I can investigate / suggest some new feature
> re: inlining.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120716/71fd3342/attachment.html>
More information about the Mono-devel-list
mailing list