• Iain Buclaw (47/47) Nov 15 2013 In the past, -femit-templates was a bit of an obtuse

"Iain Buclaw" <ibuclaw ubuntu.com> writes:

In the past, -femit-templates was a bit of an obtuse 
implementation.

You had quite a few options:
- none    -> don't emit any templates
- all     -> force emit all templates, even ones that were 
discarded by the front-end / had problems instantiating but were 
gagged.
- private -> same as 'all', but emit them privately rather than 
weak for targets that didn't support.
- normal  -> emit (subjective to whether or not the backend 
infers that it is referenced) this symbol if the front-end tells 
us to.
- auto    -> either 'normal' or 'private' depending on if the 
target supported weak.

This was a bit hairy to work with, as any bug fixes around 
emission problems could have had a knock-on effect that breaks 
the other switches.  So for the sake of simplicity - I removed 
'all' and 'auto' and kept just the three behaviours.  The default 
being 'normal' unless -femit-templates/-fno-emit-templates was 
used, then the compiler either emitted everything privately, or 
nothing at all.  The fact that this was kept around at all was 
because there were still some problems with the gcc backend 
removing functions from the compilation it deemed unreferenced 
and uneeded, but had their address taken nonetheless causing all 
sorts of undefined linker errors in certain edge cases.

In gcc-4.9, we now have a way to override gcc's symbol 
elimitation via cgraph(decl)->forced_by_abi.  Along with the 
front-end's new template emission behaviour and an -allinst 
switch to turn on the pre-2.064 release behaviour, this has given 
us another opportunity to change and clean-up -femit-templates.

This is the score:
- Default behaviour is the same as in D 2.064
- -femit-templates is mapped to -allinst, all special code 
removed from the glue.
- -fno-emit-templates still means that no instantiated templates 
will be emitted to object file.

With that, we no longer require any special-case analysis of the 
front-end codegen [¹][²][³]


So, no more hacks in the front-end, the ability to switch between 
pre-2.064 and 2.064 template instantiation behaviour, and having 
a peace of mind that the compiler will emit what it's told to 
emit.  You'd think it's all looking good, wouldn't you...  :o)


[1]: https://github.com/D-Programming-Language/dmd/pull/2723
[2]: 
https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/dfrontend/template.c#L5142
[3]: 
https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/dfrontend/template.c#L5171