llvm dev - Sep 2007 - [LLVMdev] Compiling zlib to static bytecode archive

On Wednesday 26 September 2007, Chris Lattner wrote:
> > llvm-gcc calling llvm-ld:
> >   llvm-gcc -> llvm-ld -> gcc -> collect2 -> ld
> >
> > enhance collect2:
> >   llvm-gcc -> llvm-collect2 -> llvm-ld -> gcc -> collect2
-> ld
>
> I'd rather enhance collect2 like this:
>
> llvm-gcc -> llvm-collect2(liblto) -> ld
>
> Where llvm-collect2 is just collect2 that dlopen's liblto to do the
> optimization work. This makes it work much more naturally than adding
> a whole new set of steps.  Depending on llvm-ld will never get you to
> a world where LTO is transparent, because llvm-ld doesn't support a
> lot of options and features that native linkers do.
So the llvm-collect2 will combine the functionality of the original collect2 
and of llvm-ld?

When it executes, it would take the following steps:
1. for each input, determine whether it is in bytecode or native format
2. if there are no bytecode inputs, go to step 6
3. link the bytecode inputs and optimize the resulting bytecode, using liblto
4. if bytecode output was requested, we are done
5. generate native object in a temporary file
6. perform the init/exit fixups that the original collect2 does
7. invoke system linker to link the generated native object (if any) and the 
input native objects (if any)

Assuming those steps are correct, step 6 and 7 could be implemented by using 
the original collect2 and adding the generated native object to the list of 
files to link. In other words, llvm-collect2 could be a separate process, 
which is called instead of collect2, does some processing and then runs the 
original, unmodified collect2:
  llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld

Bye,
		Maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070926/0f16aebb/attachment.sig>

On Sep 25, 2007, at 6:12 PM, Maarten ter Huurne wrote:
> On Wednesday 26 September 2007, Chris Lattner wrote:
>
>>> llvm-gcc calling llvm-ld:
>>>   llvm-gcc -> llvm-ld -> gcc -> collect2 -> ld
>>>
>>> enhance collect2:
>>>   llvm-gcc -> llvm-collect2 -> llvm-ld -> gcc ->
collect2 -> ld
>>
>> I'd rather enhance collect2 like this:
>>
>> llvm-gcc -> llvm-collect2(liblto) -> ld
>>
>> Where llvm-collect2 is just collect2 that dlopen's liblto to do the
>> optimization work. This makes it work much more naturally than adding
>> a whole new set of steps.  Depending on llvm-ld will never get you to
>> a world where LTO is transparent, because llvm-ld doesn't support a
>> lot of options and features that native linkers do.
>
> So the llvm-collect2 will combine the functionality of the original  
> collect2
> and of llvm-ld?
>
> When it executes, it would take the following steps:
> 1. for each input, determine whether it is in bytecode or native  
> format
> 2. if there are no bytecode inputs, go to step 6
> 3. link the bytecode inputs and optimize the resulting bytecode,  
> using liblto
> 4. if bytecode output was requested, we are done
> 5. generate native object in a temporary file
> 6. perform the init/exit fixups that the original collect2 does
> 7. invoke system linker to link the generated native object (if  
> any) and the
> input native objects (if any)
Yep, exactly.
> Assuming those steps are correct, step 6 and 7 could be implemented  
> by using
> the original collect2 and adding the generated native object to the  
> list of
> files to link. In other words, llvm-collect2 could be a separate  
> process,
> which is called instead of collect2, does some processing and then  
> runs the
> original, unmodified collect2:
>   llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld
Sure, this would also work.  Is there any reason not to merge them  
together?

-Chris

On Wednesday 26 September 2007, Chris Lattner wrote:
> > Assuming those steps are correct, step 6 and 7 could be implemented
> > by using
> > the original collect2 and adding the generated native object to the
> > list of
> > files to link. In other words, llvm-collect2 could be a separate
> > process,
> > which is called instead of collect2, does some processing and then
> > runs the
> > original, unmodified collect2:
> >   llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld
>
> Sure, this would also work.  Is there any reason not to merge them
> together?
Ease of maintenance, mainly. Having it in a separate file makes it easier to 
migrate the code to new GCC releases. Also, collect2.c is already 2658 lines, 
which is more than I typically like to have in a single source file.

I'd like to turn the question around: is there an advantage to merging them?

In any case, if I can make it work as a separate process, it shouldn't be
hard
to merge it into collect2 later.

Bye,
		Maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070926/ea8d9762/attachment.sig>