Re: Update LTO plugin interface

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Dec 1, 2010 at 11:44 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Wed, Dec 1, 2010 at 1:28 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>> For linker script, archive, DSO and object file without IR,
>>>> *claimed will return 0 and plugin will save and pass it back to
>>>> linker later in ?if it is specified at command line.
>>>
>>> I don't understand what you wrote, so I am going to write what I think
>>> happens.
>>>
>>> The claim_file handler is an interface provided by the plugin itself.
>>> The plugin will register it via LDPT_REGISTER_CLAIM_FILE_HOOK. ?The
>>> linker proper will call it for each input file.
>>>
>>> In the case of the LTO plugin, this is the static function
>>> claim_file_handler in lto-plugin.c.
>>>
>>> If the plugin registers a claim_file handler, and, when the linker calls
>>> it, it returns with *claimed == 0, then the linker will process the file
>>> as it normally does. ?Since the file will already have been processed,
>>> it does not make sense for the plugin to then pass it back to the
>>> linker. ?The effect would be similar to listing the file twice on the
>>> command line.
>>
>> That is what "Discard all previous inputs" in stage 2 linking is for.
>
> But what does that mean? ?Are you saying that the linker interface to
> the plugin should change to work that way? ?If we do that, then we
> should change other aspects of the plugin interface as well. ?It could
> probably become quite a bit simpler.
>
>
> The only reason we would ever need to do a complete relink is if the LTO
> plugin can introduce arbitrary new symbol references. ?Is that ever
> possible? ?If it is, we need to rethink the whole approach. ?If the LTO
> plugin can introduce arbitrary new symbol references, that means that
> LTO plugin can cause arbitrary objects to be pulled in from archives.
> And that means that if we only run the plugin once, we are losing
> possible optimizations, because the plugin will never those new objects.
>
>
> My suspicion is that the LTO plugin can only introduce a small bounded
> set of new symbol references, namely those which we assume can be
> satisified from -lc or -lgcc. ?Is that true?

At the moment it would be -lc -lgcc -lm -lpthreads I guess (and maybe
some others, dependent on the target), maybe also our own runtimes
like libssp, libgomp, etc..

The biggest issue is that we can introduce new uses of symbols that the user
is allowed to provide.  For example the linux kernel has a local implementation
of divdi3 because it doesn't want to link libgcc.  If that implementation
is in a static library without LTO bytecode we have to re-consider
that static archive after link-time optimization.

Richard.

> Ian
>