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
