Custom calling conventions

[Jacob Carlborg]

On 2012-02-22 19:39, Michel Fortin wrote:
> 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.
>

Yes, exactly.

-- 
/Jacob Carlborg