D to ASM.js vs D to Dart (VM)

[Paulo Pinto via Digitalmars-d]

Am 18.05.2014 10:18, schrieb bearophile:
> Paulo Pinto:
>
>> Am 18.05.2014 10:02, schrieb bearophile:
>>> But in general isn't it more efficient to not generate bloat instead of
>>> generating it, detecting it, and removing it?
>>>
>>> Bye,
>>> bearophile
>>
>> Which you can only do if the compiler can see the whole code.
>>
>> It doesn't work in binary libraries.
>
> I think in this case avoiding part of the problem is better than
> avoiding none of it :-) There are other similar situations where
> avoiding the template bloat is useful. This generates two instances of
> doubleIt in the binary:
>
>
> T doubleIt(T)(T x) { return x * 2; }
> void main() {
>      immutable r1 = doubleIt(10);
>      immutable r2 = doubleIt(cast(const int)10);
> }
>
>
> The asm, from DMD:
>
> _D4temp15__T8doubleItTiZ8doubleItFNaNbNiNfiZi:
>          enter   4,0
>          add EAX,EAX
>          leave
>          ret
>
> _D4temp16__T8doubleItTxiZ8doubleItFNaNbNiNfxiZxi:
>          enter   4,0
>          add EAX,EAX
>          leave
>          ret
>
> Bye,
> bearophile


Right, but what about more complex examples with nested templates, 
mixins and inlining?

At what moment does the optimizer give up and passes the work down to 
the linker?

Usually the work is done on basic block level, it doesn't have the full 
picture.

There are a few interesting talks from LLVM where Chandler Carruth shows 
how pages of code can be generated out of innocent looking code, because 
of nested calls.

--
Paulo