Am Wed, 26 Nov 2014 17:19:25 +0000 schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> On 26 November 2014 at 15:40, Johannes Pfau via D.gnu > <d.gnu@puremagic.com> wrote: > > Has anybody had a closer look at cross-module inlining? > > What exactly is necessary to get it working and how difficult would > > it be to implement? > > > > AFAICS > > * We'd need to do semantic3 on all imported modules > > * We'd have to call (a modified) toObjfile on all functions from > > imported modules > > > > However, we of course can't emit the functions so could we mark them > > as EXTERN? I've also tried to do that, but in non-toy examples > > GDC always crashes somewhere. Do we also need to call toObjfile for > > variables, classes, etc used in these functions (of course somehow > > without emitting symbols)? > > > > All in all this seems to be a complicated task, correct? > > As best as I can explain it: > > - Inlining never occurs because there is no body (that has been > converted to gcc). > - The front-end knows the body, however semantic3 pass must be ran > before attempting inline (in the front-end). > - toObjFile performs the entire compilation in one swoop; generate > body, add to cgraph/global decls and send to backend to compile. > > I'm not sure of where you are getting the ICE/crash, but there is one > or two scenarios: > > 1) We only need the tree body to be available. > > For inlining to occur, we only need part of what toObjFile already > does for us. Yes, generate the body, no do not add to the global > decls/perform any finalisation for us. > > We should not need to explicitly mark the function as EXTERN as it has > been defined (it has a body). But by not emitting the function to the > backend, guarantees that the function won't appear in assembly. > > 2) We need the body to be gimplified. > > This is trickier. Hopefully the gcc inline pass will do the > gimplification for us. But if that is not the case, then we are going > to have to go about marking the function as EXTERN INLINE, send it to > the backend for compilation - complicating our codegen routines in the > process. OK, we do have to call cgraph_node::finalize_function. And from tree.h: Note that this does not necessarily imply the entity represented by NODE has no program source-level definition in this translation unit. For example, for a FUNCTION_DECL, DECL_SAVED_TREE may be non-NULL and DECL_EXTERNAL may be true simultaneously; that can be the case for a C99 "extern inline" function. */ #define DECL_EXTERNAL(NODE) Here's a first try: https://github.com/jpf91/GDC/commit/919efaa2246e2f56a021f57b0991476f82c8eee5 If you see some obvious problems, please comment ;-) This is good enough for simple test cases, however, even importing std.stdio crashes somewhere in the mangle code. Maybe I'll have to do some of the checks in output_declaration_p for inlining as well.
