DMD hackers: pragma(address): Is this possible?

[Iain Buclaw via Digitalmars-d]

On 25 November 2014 at 19:08, Daniel Murphy via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> "Johannes Pfau"  wrote in message news:m5288s$l8$1 at digitalmars.com...
>
>> No, unfortunately not. The module where the template is instantiated
>> needs to be the 'main' module. Or rather toObjfile must have been
>> called on the function for backend inlining. Unfortunately this seems
>> to be a complicated task.
>
>
> Would it make sense to always call toObjfile for always-inline template
> functions?  That should be harmless...


That depends....

There's a bit of a split-brain scenario going on (or maybe catch-42).

In the current architecture of DMD, there are two states, front-end
and back-end.  However in GDC, there are four states, front-end (DMD),
front-end (GCC), middle-end and back-end.

But let's ignore the last two, they don't have anything to do with us.
There's just two states we are dealing with here:  Front-end (AST of
the source code analysed by DMD), and back-end (AST of the code
generator for compiling down to object file/assembly).

As it stands, the front-end AST holds more information than the
back-end AST.  This is because what get sent to the back-end (via
toObjFile) is done for the intention of being written to the final
object/assembly code, no questions asked.  For DMD, this I guess is
reasonable because its back-end has limited heuristic analysis. Where
as in GCC we almost an overkill amount of it, to the point were we
must "force_by_abi" the output of every symbol.

This was not necessarily the intention, but due the preferred method
of compilation (single), and the "selective" nature when it comes to
template emission under this model; the back-end just cannot be
trusted to make certain (size) optimisations, as 90% of the time it
turns out to be in the wrong because it never gets enough information
in it's callgraph to correctly determine what should and should not be
emitted (we are back to the front-end knowing more information than
the back-end).

What would be ideal is something inbetween.  Lets call this middle-end AST.

A middle-end AST is built alongside or immediately after the front-end
AST.  Lets say for the most likely scenario, immediately after
semantic3 processing has finished, which is the best time to do such
things.  This middle-end AST may allow for certain optimisations or
heuristic analysis to be done that cannot be done in the front-end
semantic processing (think of any warnings or code re-writes that we
must currently do in the back-end - no doubt come with the comments:
HACK, FIXME, or BUG XXX).

The crucial thing to understand though is that the middle-end AST is
just a transitive layer. Nothing done here is guaranteed to be emitted
to the resultant object file unless it lands at toObjFile.  At this
point, the middle intermediate representation gets lowered/send it
down for finalising the compilation.

But, I guess we now have visitors for this sort of thing, so....

tl;dr

foreach(m; module)
{
  m.semantic();
  ToBackendVisitor::accept(m);  // pre-build back-end AST (doesn't exist)
}

foreach(m; module)
{
  if (m in output_modules)
    m.toObjFile();  // Now send to object file
}


--
Iain