Re: "ld -r" on mixed IR/non-IR objects (

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Dec 7, 2010 at 4:20 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>> Here is my proposal. ?Any comments?
>>
>> We talked about ld -r a while back during the WHOPR project, and the
>> two ways that the linker could work: (1) combine all the .o files and
>> use the plugin to run LTRANS on the IR files, producing a pure,
>> optimized, object file; and (2) combine the non-IR object files as ld
>> -r normally would, and combine that result somehow with the IR from
>> the other files, for later optimization. If I remember correctly,
>> there was support for both modes of operation. The first mode is
>> easily handled with the current design (untested as far as I know --
>> there are probably bugs, and I'm not sure if we get the symbol
>> visibility correct in those cases).
>
> the first mode is imho useless because you'll never get whole program
> optimizations this way. I tested it some time ago and it worked in a
> limited way
> (there were some problems that gcc crashed if you didn't specify
> -fwhole-program which would be obviously a lie, but those might be fixed
> now)
> But it won't give you the LTO advantages in any case.
>
> I implemented (2) by giving the sections appropiate names
> so they don't get messed up. this works today with gcc mainline, as
> long as all objects in the combined object are LTO.
>
> The only problem left is mixing of lto and non lto objects. this right
> now is not handled. IMHO still the best way to handle it is to use
> slim lto and then simply separate link the "left overs" after deleting
> the LTO objects. This can be actually done with objcopy (with some
> limitations), doesn't even need linker support.
>

My proposal should address mixing of lto and non lto objects.


-- 
H.J.