Custom calling conventions

[Michel Fortin]

On 2012-02-22 17:32:14 +0000, Jacob Carlborg <doob at me.com> said:

> On 2012-02-22 13:53, Michel Fortin wrote:
>> On 2012-02-22 07:41:21 +0000, Jacob Carlborg <doob at me.com> said:
>> 
>>> void foo (T) () {}
>>> void main ()
>>> {
>>> foo!(int);
>>> foo!(char);
>>> }
>>> 
>>> $ dmd -inline -O -release main.d
>>> $ nm main | grep foo
>>> 
>>> 00000001000012b8 T _D4main10__T3fooTaZ3fooFZv
>>> 00000001000012b0 T _D4main10__T3fooTiZ3fooFZv
>>> 
>>> Outputs two symbols as expected, one for each instantiation.
>> 
>> That's expected indeed.
>> 
>> This doesn't mean the inliner will not inline the templates. In fact, if
>> you correct the example and look at the assembler output you'll see it
>> will (in your example there is nothing to inline since you're just
>> instantiating the template without calling it).
>> 
>> What doesn't happen is stripping the unreferenced symbols from the
>> executable. On OS X, try adding "-L-dead_strip" to DMD's argument to
>> instruct the linker to do so.
>> 
> 
> 1. The example is correct, you can call a method without parentheses

Ah, seems I forgot this.

> 2. Adding -L-dead_strip does not seem to strip the "foo" symbols
> 3. Adding -L-dead_strip causes a segmentation fault with this example 
> (DMD 2.057)
> 
> import std.stdio;
> 
> void foo (T) () { writeln("asd"); }
> void main ()
> {
>       foo!(int);
>       foo!(char);
> }

I'm still on v2.055. And I can confirm -L-dead_strip worked for me, but 
I did a change similar to yours so the template was calling printf 
(that makes it easier to see if it was inlined when looking at the 
assembly). Everything worked as expected with printf. Calling writeln, 
which is a template itself, which could be inlined into foo, could 
cause foo to not be inlined, although it doesn't explain the segfault.

I'm starting to suspect the empty version of foo doesn't get inlined 
for some reason.


> 4. I thought the reason for the big executable using the Objective-C/D 
> bridge was due to all these template symbols.

I might have been, but I'd be surprised I didn't try striping the 
executable to fix the problem.

In the end, mostly all the instantiated code has to be there for the 
virtual tables. There's almost one instanciation per method, and that 
is a lot of bloat. Whether the template instanciation is inlined or not 
just changes under which symbol the code resides, the code doesn't 
magically disappear, it still has to be there somewhere.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/