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

Reply via email to