On inlining in D libraries

[Dmitry Olshansky]

09-Sep-2013 21:42, Johannes Pfau пишет:
> On Monday, 9 September 2013 at 14:58:56 UTC, Dmitry Olshansky wrote:
>> 09-Sep-2013 18:39, Joseph Rushton Wakeling пишет:
>>> On 09/09/13 16:34, Dmitry Olshansky wrote:
>>>> On the bright side of things std.regex is real fast on LDC *when
>>>> hacked* to
>>>> inline the critical bits :)
>>>
>>> Do you mean when manually inlined, or when the design is tweaked to
>>> facilitate inlining?
>>
>> When I put extra () to indicate that said functions are templates.
>> Then compiler gets its grip on them and finally inlines.
>> Otherwise it generates calls and links in object code from libphobos.
>>
>> Which is the whole reason for the topic - is THAT is the way to go?
>> Shouldn't compiler look into source for inlinable stuff (when source
>> is available)?
>>
>
> I only know about GDC and GDC doesn't implement cross-module inlining
> right now. If the modules are compiled in a single run it might work but
> if the modules are compiled separately then only LTO (not tested with
> GDC though!) can help.
>
> AFAIK the problem is this: There's no high-level way to tell the backend
> "hey, I have the source code for this function. if you consider inlining
> call me back and I'll compile it for you". The only hack which could
> work is _always_ compiling _all_ functions from all modules. But compile
> times will explode.

Precisely the problem we have and the current state of things. Compiling 
everything would be option B).

The solution sought after is not how to hack this around but how to make 
everything work nicely out of the box (for everybody).

> Another issue is that whether a function will be inlined depends on
> details like the number of compiled instructions. Those details are only
> available once the function is compiled, the source code is not enough.
>
> Maybe a reasonable compromise could be made with some help from the
> frontend. The frontent could give us some hints ("Likely inlineable").
> Then we could compile all "likely inlineable" functions and let the
> backend decide if it really wants to inline those.
>
> (Another options is inlining in the frontend. DMD does that right now
> but IIRC it causes problems with the GCC backend and is disabled in
> GDC). Iain can probably give a better answer here.

DMD's AST re-writing inliner is rather lame currently, hence just not 
worth the trouble I suspect.

>
> (Note: there's a low-level way to do this: LTO actually adds
> intermediate code to the object files. If the linker wants to inline a
> function, it calls the compiler to compile that intermediate code:
> http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html . In the end
> working LTO is probably the best solution.)

LTO would be the best solution but at the moment it's rather rarely used 
optimization with obscure issues of its own.

It makes me think that generating generic (& sensible) IR instead of 
object code and doing inlining of that is a cute idea.. but wait that's 
what LLVM analog of LTO should do.

-- 
Dmitry Olshansky