Cross-module inlining

[Iain Buclaw via D.gnu]

On 26 November 2014 at 15:40, Johannes Pfau via D.gnu
<d.gnu at 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.