Yigal Chripun wrote:
> Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.

It does open up a lot of possibilities.

One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat.

Currently, COMDATs are merged if and only if their names match exactly.

Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.

Walter Bright wrote:
> Yigal Chripun wrote:
>> Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.
> 
> It does open up a lot of possibilities.
> 
> One I think would be of big benefit is for two COMDATs with different names, but the same contents, being merged. This would eliminate a lot of template bloat.
> 
> Currently, COMDATs are merged if and only if their names match exactly.
> 
> Another possibility is to merge the linker with dmd, so it can generate executables directly without having to go through an object file step.

Well it opens up a lot of possibilities *on Windows only*, which is liable to dampen some enthusiasm.

Andrei

On 04/11/2009 00:18, Walter Bright wrote:
> Yigal Chripun wrote:
>> Once Optlink is moved to C and than D, it could grow new features like
>> link-time optimizations.
>
> It does open up a lot of possibilities.
>
> One I think would be of big benefit is for two COMDATs with different
> names, but the same contents, being merged. This would eliminate a lot
> of template bloat.
>
> Currently, COMDATs are merged if and only if their names match exactly.
>
> Another possibility is to merge the linker with dmd, so it can generate
> executables directly without having to go through an object file step.

Merging the linker with DMD is an excellent idea. There still should be a flag to generate object files, but in general there are only two useful artifacts the compiler should generate: executable and lib.
I'd want to see also integration of DDL or something similar in concept so the libs generated by DMD could be used as shared libs.

Another feature that would be nice to have is incremental compilation. each time you run dmd it would update the previous lib file with the delta of changes instead of regenerating it from scratch.

Bill Baxter wrote:
> 
> So is it any slower now with things not in ASM?
> 
> --bb
> 

You are not serious are you? The linker not the linked?

If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?

Tim Matthews Wrote:

> Bill Baxter wrote:
> > 
> > So is it any slower now with things not in ASM?
> > 
> > --bb
> > 
> 
> You are not serious are you? The linker not the linked?
> 
> If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?

it will be slower - I want my 100ms back.

Walter Bright wrote:
> Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).

And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.

And no, GNU ld is not too slow. The most time during building is wasted due to not having _working_ incremental building (Tom S discussed the issues about that with you). Additionally, I prefer a slow, working linker over a fast, crashing one.

On Wed, Nov 4, 2009 at 12:28 AM, Tim Matthews <tim.matthews7@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> So is it any slower now with things not in ASM?
>>
>> --bb
>>
>
> You are not serious are you? The linker not the linked?
>
> If it's functionally more correct, easier to understand and easier to implement link time optimizations then how can anyone justify asm to c transition (where asm is not required) as a disadvantage?

Walter often defends sticking with OPTLINK because it is fast.  And the implication is that it is fast in part because it's all in hand-coded ASM.  I was merely curious if that was holding up or not, or if in fact being in ASM was irrelevant to the speed.  I would think linkers would be mostly IO bound since they do fairly simple things with large amounts of data, so that would argue that it shouldn't matter much whether it's in ASM or C.

--bb

grauzone, el  4 de noviembre a las 17:23 me escribiste:
> Walter Bright wrote:
> >Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
> 
> And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
> 
> And no, GNU ld is not too slow.

And if you really find it slow, GNU Gold (done by Google) is *much*
faster.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Robar un alfajor es revolucionario, pues rompe con la idea de propiedad,
incluso más que si se tratara de dinero.
	-- publikazion anarkista mdp (hablando de los destrozos de la
	   Cumbre de las Americas en Mar del Plata, 2005)

On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax@gmail.com> wrote:
> grauzone, el  4 de noviembre a las 17:23 me escribiste:
>> Walter Bright wrote:
>> >Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
>>
>> And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
>>
>> And no, GNU ld is not too slow.
>
> And if you really find it slow, GNU Gold (done by Google) is *much*
> faster.

Interesting.

Detailed series of 20 blog posts by the author here:

http://www.airs.com/blog/archives/38
http://www.airs.com/blog/archives/39
...
http://www.airs.com/blog/archives/57

Looks like interesting reading.

--bb

Bill Baxter, el  4 de noviembre a las 11:08 me escribiste:
> On Wed, Nov 4, 2009 at 10:21 AM, Leandro Lucarella <llucax@gmail.com> wrote:
> > grauzone, el  4 de noviembre a las 17:23 me escribiste:
> >> Walter Bright wrote:
> >> >Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
> >>
> >> And during all that time, GNU ld worked just fine, completely without bugs! I had to add hacks to my code to make it linkable on Windows.
> >>
> >> And no, GNU ld is not too slow.
> >
> > And if you really find it slow, GNU Gold (done by Google) is *much*
> > faster.
> 
> Interesting.
> 
> Detailed series of 20 blog posts by the author here:

BTW, Gold already support LTO (LInk Time Optimization) via plug-ins for
both GCC (meaning GDC could use it in the future) and LLVM (meaning LDC
could use it in the future, maybe even now, I didn't test it).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
CAYO HUGO CONZI  ---  TENIA PUESTA PELUCA
	-- Crónica TV