[llvm-dev] Refining which symbols are preemptable with lto
Sean Fertile via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 14 08:36:37 PDT 2017
Thank you for such detailed instructions Peter!
On Wed, Jun 14, 2017 at 2:03 AM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Tue, Jun 13, 2017 at 9:43 PM, Sean Fertile via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> As a follow up to https://reviews.llvm.org/D20217 I would like to use
>> lto/thinlto to refine when a symbol is marked as local/preemptable.
>> I'm not very familiar with lto though so would appreciate some
>> guidance about how best to go about this.
> Hi Sean,
> The first thing that I would do is to try to get this working for regular
> LTO. There is a flag in the lto::SymbolResolution class named
> FinalDefinitionInLinkageUnit, which was intended to control whether the
> backend must make symbol references preemptible. Right now we copy a number
> of other fields from SymbolResolution onto the symbol definition, which is
> done by LTO::addRegularLTO in this loop:
> I imagine that this is where you would add code that translates
> FinalDefinitionInLinkageUnit into dso_local/dso_preemptible.
> The next step would be to get it working for ThinLTO. This would involve the
> same basic mechanism: the FinalDefinitionInLinkageUnit flag would control
> whether to set dso_local/dso_preemptible on global values. The difference
> would be that the flag would need to be passed via the module summary index,
> as this is how information needs to be passed to the ThinLTO backends. The
> way that I imagine that this would work is that we would introduce a new
> flag in GlobalValueSummary::GVFlags into which you would copy the value of
> FinalDefinitionInLinkageUnit during LTO::addThinLTO. We already copy the
> Prevailing flag elsewhere using the GUID:
> but for this flag I imagine that you would want to copy it directly into the
> global's summary (see ModuleSummaryIndex::getValueInfo for how to look up a
> global value summary using a GUID).
> The default value of this flag should mean "preemptible" -- Apple's linker
> uses a legacy API which will not set this flag, so that avoids breaking
> their linker.
> Then in the thinBackend function you would translate the flag into
> dso_local/dso_preemptible. Probably the best place to do that is in
> FunctionImportGlobalProcessing::processGlobalForThinLTO here:
> See shouldPromoteLocalToGlobal for how to find the summary for the
> GlobalVariable at that point -- some of that code probably needs to be
> factored out.
> There would also need to be bitcode reader/writer support for the new flag:
> There is one subtlety however, which is that the summary index might not
> contain entries for functions without definitions. For now I would punt on
> this and mark declarations that are not present in the summary index as
>> Sean Fertile
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev