• Maxime Larose (23/23) Apr 25 2005 Is inlining currently supported? Or is it far less aggressive than it co...
• Uwe Salomon (9/13) Apr 26 2005 The compiler "calculates" if the inlining is worthwhile, but i do not kn...

"Maxime Larose" <mlarose broadsoft.com> writes:

Is inlining currently supported? Or is it far less aggressive than it could?
I see a lot of methods that seem to me like ideal candidates for inlining
that don't get inlined. One obvious case is a small naked asm function that
does an atomic increment. Ex:
void (uint* value) {
asm {
  naked;
  lock;
  add [EAX], 1;
}
}

For some reason, this doesn't get inlined.
(I didn't actually run the above code, so there might be syntax problems,
etc. Bottom line still holds though, I saw it in many instances.)



Also, the DMD compiler generates code that use the INC and DEC instructions.
Intel recommend that these instructions be avoided because they have flag
dependancies on previous instructions (which screws up the out-of-order
execution engine and slows down the processor). ADD and SUB should be used
instead (when preserving flags isn't a concern, obviously). Any reasons why
INC and DEC are still generated by DMD?  The only reason I see is it uses
less code space, but who cares about a few more bytes in an executable?

Thanks,

Max

"Uwe Salomon" <post uwesalomon.de> writes:

 Is inlining currently supported? Or is it far less aggressive than it  
 could?

Yes it is, add -inline to the compiler options.

 I see a lot of methods that seem to me like ideal candidates for inlining
 that don't get inlined.

The compiler "calculates" if the inlining is worthwhile, but i do not know  
how. What i found out is that he does inline very large functions if you  
simply give them the parameters, but he does not inline even small ones if  
you do something with the parameters. Example:

notTooBigFunction(a, b); // Mostly gets inlined.
verySmallFunction(a++, b); // Seldomly gets inlined?

Ciao
uwe