[PATCH] D17212: [ThinLTO] Support for call graph in per-module and combined summary.

[Xinliang David Li via llvm-commits]

Is there a need to mark it? Does the following work?
1) using summary call graph to do importing decision
2) for any function that is imported by another module, mark it as
'exported'
3) When processing the exporting module, check any exported function and
promote any statics it references.

David



On Fri, Feb 26, 2016 at 10:38 AM, Teresa Johnson <tejohnson at google.com>
wrote:

> tejohnson added a comment.
>
> In http://reviews.llvm.org/D17212#362864, @joker.eph wrote:
>
> > How could we integrate accesses to global variable as part of this?
> >  It turns out that to be able to benefit from the linker information on
> what symbol is exported during the import, this is a must.
>
>
> Well without it you still can see which function symbols will be exported,
> just not the variables, so you are running with less info and I guess need
> to assume that all static variables will be exposed and promote them. To
> refine that behavior for variables, yes, we'd need additional info in the
> summary.
>
> (For davidxl or anyone else who didn't see the IRC conversation, Mehdi is
> looking at doing pure summary-based importing decisions in the linker step,
> then giving this info to the ThinLTO backends to avoid promotion of local
> values that aren't exported. For a distributed build if we wanted to do it
> this way the importing decisions would all be made in the plugin step, then
> would need to be serialized out for the distributed backends to check.)
>
> Two possibilities depending on the fidelity of the info you think you need:
>
> 1. One possibility is to just put a flag in the function summary if it
> accesses *any* local variables, and adjust the importing threshold
> accordingly. Then in the ThinLTO backend for the exporting module you need
> to check which of your own functions are on the import list, and which
> local variables they access, and promote accordingly.
>
> 2. If it will be really beneficial to note exactly which local variables
> are accessed by which function, we'll need to broaden the edges list to
> include accesses to variables (I assume you only care about local variables
> here). E.g. the per-module summary edge list for a function would need to
> include value ids for any local variables referenced by that function (not
> sure that the other parts of the triple, the static and profile counts, are
> needed for that). Then in the combined VST we need to include entries for
> GUIDs of things that don't have a function summary, but are referenced by
> these edges. When accessing a function summary edge list for a candidate
> function to import, you could then see the GUID of any local variables
> accessed. You wouldn't know them by name, but if for example you wanted a
> heuristic like "if >=N hot import candidate functions from module M access
> a local variable with GUID G, go ahead and import those and let G be
> promoted by the backend (which like in approach #1 needs to check which
> local variables are accessed by any functions on an import list)".
>
> Obviously 1) is easier and cheaper space-wise. What are your thoughts?
>
>
> http://reviews.llvm.org/D17212
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160226/47db7130/attachment.html>