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
