[llvm] [ThinLTO]Record import type (declaration or definition) in GlobalValueSummary::GVFlags (PR #87597)

Jan Voung via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 8 08:47:36 PDT 2024


================
@@ -737,6 +737,7 @@ lltok::Kind LLLexer::LexIdentifier() {
   KEYWORD(live);
   KEYWORD(dsoLocal);
   KEYWORD(canAutoHide);
+  KEYWORD(importAsDec);
----------------
jvoung wrote:

The use case is to propagate more function and param attributes across modules (beyond the ones currently in `FFlags`, and usually requiring knowledge of the body vs the call edges, unlike `NoRecurse`). The main one I'm interested in is the `initializes` one under review (https://github.com/llvm/llvm-project/pull/84803) but in general a few other attributes inferred by FunctionAttrs pass like readonly, nocapture, ... Not more complex and uninteresting attributes like `byval<ty>`.

We found that at least pre-link, there would need to be some info recorded about whether there are "interesting" attributes to propagate to trigger this fallback for too large or noinline cases. Otherwise, always importing the  fallback would be too much (from Mingming's measurements). Options for info to record pre-link considered:

1. subset of interesting attributes themselves (e.g., a subset of the hash-consed AttributeList)
2. or, a flag that just indicates there are "enough" interesting attributes as a hint for the indexing step

Some pros for option 1 and import summary
- we could import the summary instead as an even lighter weight option than import dec -- the summary holds the info so we don't need the IR. One FDO-based experiment on a large app: about 15% more function summary copies and 30% more "from" modules summaries. This is when we consider `initializes`, FFlags `ReadOnly`, `ReadNone`,  and `NoRecurse` as interesting attributes. I skipped `NoUnwind` since the app is compiled with `-fno-exceptions` and a lot of functions would have `NoUnwind`. May increase if we add other param attributes.
- may eventually help handle vague linkage attribute inference to handle a de-refinement problem in a lighter weight manner (intersecting summary-only attributes and propagating) than an alternative of importing the prevailing definition's bodies. We have some discussion of this elsewhere.

Some pros for option 2 and just import decl
- simpler summary
- simplicity of one fallback option instead of two

https://github.com/llvm/llvm-project/pull/87597


More information about the llvm-commits mailing list