A modest proposal: eliminate template code bloat

[Dmitry Olshansky]

On 08.04.2012 19:59, Artur Skawina wrote:
> On 04/08/12 17:20, Dmitry Olshansky wrote:
>> On 08.04.2012 18:21, Artur Skawina wrote:
>>> On 04/08/12 13:01, Dmitry Olshansky wrote:
>>>> 3. After any function was generated compiler checks an entry in the duplicate table that matches size, followed by matching checksum and only then (if required) doing a straight memcmp. If it happens that there is a match compiler just throws generated code away and _aliases_ it's symbol to that of a matched entry.
>>>> (so there has to be an alias table if there isn't one already)
>>> [...]
>>>> Thoughts?
>>>
>>> Don't forget that this needs to work:
>>>
>>>      static auto f(T)(T a) { return a; }
>>>      assert(cast(void*)&f!int!=cast(void*)&f!uint);
>
>> A reference to spec page plz.
>
> A reference to *a* D spec, please...

Yeah, sorry.
>
> There isn't one, but that does not mean that common sense does
> not need to apply.
>

There is common sense and that is (in my book):
don't tie up compiler's hands for no benefit.

> Do you really suggest making different template instantiations
> identical, just because the compiler happened to emit the same
> code? The situation is not very different from
>
>     const int a = 1; const uint b = 1; assert(&a!=&b);
>

I wouldn't expect this assert to always hold. Moreover (all things being 
equal) I would expect taking address of constant integers a poor practice.

> The user can take the addresses, compare them, use as AA keys,
> set breakpoints etc.
>

Yes, that's what I call poor practice ( I mean function pointer as AA 
_key_, seriously?). As for breakpoints, obviously one debugs 
non-optimized program (at least most of the time).

> Note that my point is just that the compiler needs to emit a dummy
> so that the addresses remain unique, eg
>
>     module.f!uint:
>         jmp module.f!int

Could work as a conservative option. But I don't think it's justified.

>
> that only is used when taking the address. Even calling f!int()
> instead of the uint version could be acceptable, as long as there
> is a compiler option to turn this optimization off (think breakpoints).
>

Yup, that's what optimizations are.

-- 
Dmitry Olshansky