[llvm-dev] [RFC] (Thin)LTO with Linker Scripts

[Peter Smith via llvm-dev]

Hello Tobias,

Thanks very much for the response.

>> I think both cases are illustrative of a use case where the precise
>> output section does not matter, but there is a vaguer goal of placing
>> a subset of the input sections in a subset of the output sections.
>> From what I can tell there isn't a way for the code generator to tell
>> the difference between code that is placed in different output
>> sections and it is not correct or beneficial to optimize and code that
>> is placed in different output sections and it is correct and
>> beneficial to optimize together.
>
>
> Perhaps we should rename the "output section" that is communicated to LTO to
> something less specific to make it clear that it can be used for exactly
> this purpose. Optimization domain? Partition?
>

Yes I think it would help; either of those names make sense to me.

>> I think that this kind of use case could be supported by doing something
>> like:
>> - Linker informs code generator the output sections that must not use
>> any information from another module and may not contribute any
>> information to another module. For example an output section that is
>> representing an overlay.
>
>
> It's not so much about other modules (files) - you could have multiple files
> contributing input sections to the same overlay, for instance, and you would
> want to optimize across them. But you wouldn't want to de-duplicate a
> constant from another overlay. I think the
> OutputSectionID-as-optimization-domain idea captures this use case, no?
>

Yes I think each overlay could be captured by its own domain. What I
think would be useful is to allow some kind of suffix to the
optimization domain that a linker could use to recover preferences
between two Output Sections for example:
OS1 : { my_objects*(*.text) }
OS2 : { other_objects*(*.text) }

I want OS1 and OS2 to be in the same optimization domain, but I do
want to recover the preference for OS1 and OS2 at link time. If only
the optimization domain is added to the section name (the ^^) that
information will be lost. If there is some kind of way of recovering
the original OS then that would be great. For example if I passed to
the code generator "OS.1" and "OS.2" where OS is the optimization
domain and anything after the . is preserved in the section name so
that the linker can map it back to the original output section.

I think that this is more important to linker's that don't give as
much control over section ordering within an OutputSection so it is
fairly common to use multiple consecutive OutputSections to group
InputSections together. Although I could be missing something about
how I could do this with the original proposal?

>> - Linker can omit the output section information for sections that the
>> user doesn't care where they go, and let the linker decide based on
>> some size constraint later.
>
>
> That's an interesting idea to allow a 'don't care' output section ID; we
> would have to be pretty careful in defining what that means on a
> per-optimization basis. That is, am I allowed to inline a function with a
> defined output section into a function without one (probably no)? Vice versa
> (probably yes)?
>

Yes, in Arm's linker an a section in an overlay was allowed to rely on
code/data in "normal" output sections to be present so could share
things like rang-extension thunks, but obviously not vice versa. I
couldn't guarantee that the advantages would outweigh the extra
implementation complexity though.

Peter