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

> 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