Is there a way to get a list of functions that get inlined by dmd?

Scorn scorn at trash-mail.com
Tue Feb 9 13:27:16 PST 2010


Don schrieb:
> Trass3r wrote:
>>> But a big problem is that inlining seems to be done only inside one
>>> module and not across modules which makes modules with something like
>>> small helper or math functions which are used across different modules
>>> senseless.
>>>
>>
>> Yeah, I think so as well as each module is compiled separately.
>> Nevertheless my patch lists functions that aren't used in the same
>> module. Maybe I've missed something.
> 
> I don't think so. It's hard to believe that the inliner would be so
> limited.
> It'd be great to assemble some important test cases that currently fail.
> Probably 'ref' arguments are the main culprit.


Thank you very much for your answer Don. I think it might be interesting
for you too, since from what i know you are also using D for numerical
stuff.

I still hope that the inliner is not so limited. But i am sure i once
read a post from Walther where he did say that optimizations are done
only per module.

I don't hope it applies for inlining too. Because otherwise the whole
module system would be, in my humble opinion, totally unusable. Just
think about things like setter / getter methods in classes, little
math-functions which you would put in a separate math module, operator
overloading in a complex number or vector / matrix class module. When
things like these are used in a program which does a lot of numerical
computations inside in a big loop this would be a really really bad.

But from my experience (which i have to admit is not that big) small
utility functions like the following are not inlined when they are in a
separate module but are inlined when they are in the same module in
which they are called:

double min(double a, double b, double c)
{
    return a < b && a < c ? a : b < c ? b : c;
}


At the moment i help myself with mixins because they will just get
copied and pasted inside the code:

template Min(char[] a, char[] b, char[] c)
{
    const char[] Min = a~"<"~b~"&&"~a~"<"~c~"?"~a~":"~b~"<"~c~"?"~b~":"
    ~ c;
}

min.x = mixin(Min!("vertex0.x", "vertex1.x", "vertex2.x"));
min.y = mixin(Min!("vertex0.y", "vertex1.y", "vertex2.y"));
min.z = mixin(Min!("vertex0.z", "vertex1.z", "vertex2.z"));


This is (and a little bit more) is running in a tight loop which runs
about 10000000 times.

With these "optimizations" i get a speed increase about 20% percent. And
i get the same increase in speed when i just copy the same function in
the module in which the function is called. It's not the only this
function where i notice this behaviour but in all of my tiny helper
functions in the separate math-module.

So for the moment it seems for me i have the alternatives in copying
every math-helper function in every module which needs it (so it gets
inlined) which is a software-engineering nightmare because i spread the
same functionality over and over in my code or use mixins to death.

So this is why i was so interested in the question under which
conditions are functions inlined (it sometimes is very strange).

I still hope it's not true that inlinig in D is so limited but from my
experience it seems to be (at last in many cases).



More information about the Digitalmars-d-learn mailing list