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

[Scorn]

> Scorn:
> 
>> Hi bearophile. Thanks for your advice (i might try out ldc in the future
>> but now i need phobos and not tango as standard library).
> 
> I like DMD for some of the D2 features, for its speed, for allowing exceptions to be used on Windows too, for its built-in profiler and code coverage analyser that are not present in LDC, and for other small things, but I like how LDC feels more like a real-world compiler, it has smaller features like force_inline that look like coming out of a more practical compiler.
> 
> When I optimize code on LDC, I see predictable improvements of the performance, while with DMD it's like a shoot in the dark, and I usually have to avoid several tweaks of the code, otherwise I get a negative improvement.
> 
> 


I absolutely understand this :-) That is why i am using gdc at the
moment and not dmd (with all of the very nice gcc optimizations flags
for the gcc backend which improve speed substantially when comparing to dmd)


>> But since all three dmd, ldc and gdc use the same frontend, the question
>> from Trass3r still remains:
>> Under which conditions are functions/methods inlined ?
> 
> I think LDC doesn't use the inliner of the front-end and just uses the much better inliner of the back-end. So the inling rules are probably all different (but in theory the front-end knows more about the D semantics, so LDC has to work even more to regain the lost semantics).
>


That would be nice. You nearly convinced me porting my project to tango
and ldc.


> Those inling rules of C# are nice and tidy (despite it doesn't inline virtual methods, as Java HotSpot does. Aren't C# programmers complaining? C# programmers don't look obsessed with performance, this is often positive), but it's not easy to find them on most C/C++ compilers I know of.

I do program a lot in C# myself (besides programming in a lot more
languages) and when i program in C# i don't expect top-notch
performance. Why ? It's because C#'s main purpose is being a rapid
application-development language and it's very good for these kind of
things. It's not meant to be used for high-performance numerical
computing but astonishingly it is sometimes not so bad when you use it
for this purpose.

But D as a system-programming language with the ambition to be an
alternative to C / C++ has, at least in the long term, to compete with C
/ C++ regarding these things.

So when i consider using D for a project i do it because i am looking
for an alternative for doing the same thing in C++ and not C#. And it
makes me always very sad when i figure out that i can't use D
successfully because of little flaws like this. And that means another
chance of using D for a project is lost.

That's why i like your posts about benchmarking so much. They might not
be liked by parts of the community because they put the hook where it
hurts most and might be annoying sometimes but please carry on :-) (you
have at least one fan here :-) ). And please make a collection of all
the issues you have found so far and but them on a web page somewhere.


> Have you ever seen the exact inlining rules of C code compiled with GCC 4.4.3?
> 


No i have not seen yet the exact inlining rules of C code compiled with
GCC 4.4.3. But i don't need them and i don't care. Why ? Because gcc
does its job well without me knowing anything about the heuristics it
uses for inlining.

For D it's different. I have found so many times that i can increase the
speed of the generate code in D tremendously by just inlining small
pieces of code manually (or using mixins). Something i have never found
using any C++ compiler (they do it so much better than i ever could).

So i think that's why Trass3r and i are so interested in the rules D
uses for inlining.


> 
>> Do you know if ldc inlines functions/methods across modules ? (dmd
>> doesn't seem to do it and neither does gdc).
> 
> I have just done a test, normally LDC is not able to inline across modules. This is a shitty situation.



You are absolutely right here. That is a shitty situation for all D
compilers. Because it basically means that your are not able to do
decent software engineering practices (a clean separation of
functionality in different modules) without sacrifying performance. That
is a situation you have in no other language i know of and this is a big
design flaw of the module system making it nearly senseless.



> But with LDC you can perform Link-Time Optimization too (but you have to ask for it!), that in my test I've just seen is able to inline across modules.
> 


Which compiler switches do you need for this ?


> 
>> And that is bad since for an actual project i have made a separate
>> module with a lot of small utility math functions which should be
>> inlined but don't because of this. When i inline them using mixins or
>> manually i get an overall speed up of about 20%.
> 
> If you explain this problem to Walter he will surely tell you that such inlining can't be done because mumble mumble separate compilation mumble mumble was done fifteen years ago mumble mumble mumble (even if LDC is currently doing it) :-)

:-) (Big smile.)


Yes. That's what i would expect. But the whole thing is easy solvable by
not doing just a separate compilation of the modules and then linking
them together but by including the source code content of a module file
in another module file which does import it (like a C or C++ compiler
includes files). Then every function / method needed is visible while
compiling the module and the compiler can decide by using its heuristics
if a function / method is worth inlining or not. The compile times might
be a bit longer but since the grammar of D is much simpler than C++ it
would not hurt compile time so much.



> 
> Good luck,
> bearophile

Thanks. Good luck for you too.

But for this project i think i will abandon D and stick to C++ again
(even if i hate to do so) because the only options would be using mixins
all over the place or put everything in one big file (and both solutions
are ugly).


Thanks for your help.