This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>> 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.

-Andi




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]