Re: [GOLD] Additional linker parameters. Proposal.

[Ian Lance Taylor <iant at google dot com>]

Viktor Kutuzov <vkutuzov@accesssoftek.com> writes:

>> When I think of link time optimization, I think of a compiler
>> operation.  gold generates very little code, currently just PLT
>> entries and ARM stubs as far as I know.  It may be that we need
>> options to control this code, but I would have to be convinced.
>
> This looks like a disconnection point.
> You think that link time optimization does not involve code generation or a very little.
> I think that link time optimization does involve code generation and
> will involve more and more of it while more advance optimizations will
> be added.
> The code generation itself happens outside of the gold and gold itself
> could generate very little code, but gold plug-ins will, and we should
> be able to accept and deliver the accurate target information down
> through the whole tool chain.
>
> Here is a real example
>
> LLVM is one of the gold user.
> They generate an intermediate platform independent bitcode  at the
> compilation time. Then they use a gold plug-in to do LTO. At the link
> time they resolve all symbols, then run optimizations and then, at the
> end when it gets actually requested, generate a native object code.
> You can find more details here http://llvm.org/docs/LinkTimeOptimization.html.

Sure, I know about link time optimization.  But the point is that it
is not done by gold.  You were talking about command line options
controlling the target architecture.  As far as I can see so far, gold
does not need such a command line option.  I agree that there needs to
be a way to give such an option to a gold plugin.  And there already
is: --plugin-opt.

I don't want to introduce a new set of options to gold until we have a
clear understanding of what purpose they would serve.  Otherwise we
risk something like the GNU linker's emulations, a lot of powerful
mechanism which is rarely understood or used.

Ian