aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-01-17[ThinLTO] Add summary entries for index-based WPDTeresa Johnson1-4/+111
Summary: If LTOUnit splitting is disabled, the module summary analysis computes the summary information necessary to perform single implementation devirtualization during the thin link with the index and no IR. The information collected from the regular LTO IR in the current hybrid WPD algorithm is summarized, including: 1) For vtable definitions, record the function pointers and their offset within the vtable initializer (subsumes the information collected from IR by tryFindVirtualCallTargets). 2) A record for each type metadata summarizing the vtable definitions decorated with that metadata (subsumes the TypeIdentiferMap collected from IR). Also added are the necessary bitcode records, and the corresponding assembly support. The index-based WPD will be sent as a follow-on. Depends on D53890. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54815 llvm-svn: 351453
2019-01-11[LTO] Record whether LTOUnit splitting is enabled in indexTeresa Johnson1-1/+5
Summary: Records in the module summary index whether the bitcode was compiled with the option necessary to enable splitting the LTO unit (e.g. -fsanitize=cfi, -fwhole-program-vtables, or -fsplit-lto-unit). The information is passed down to the ModuleSummaryIndex builder via a new module flag "EnableSplitLTOUnit", which is propagated onto a flag on the summary index. This is then used during the LTO link to check whether all linked summaries were built with the same value of this flag. If not, an error is issued when we detect a situation requiring whole program visibility of the class hierarchy. This is the case when both of the following conditions are met: 1) We are performing LowerTypeTests or Whole Program Devirtualization. 2) There are type tests or type checked loads in the code. Note I have also changed the ThinLTOBitcodeWriter to also gate the module splitting on the value of this flag. Reviewers: pcc Subscribers: ormris, mehdi_amini, Prazek, inglorion, eraman, steven_wu, dexonsmith, arphaman, dang, llvm-commits Differential Revision: https://reviews.llvm.org/D53890 llvm-svn: 350948
2018-12-13[ThinLTO] Compute synthetic function entry countEaswaran Raman1-5/+6
Summary: This patch computes the synthetic function entry count on the whole program callgraph (based on module summary) and writes the entry counts to the summary. After function importing, this count gets attached to the IR as metadata. Since it adds a new field to the summary, this bumps up the version. Reviewers: tejohnson Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D43521 llvm-svn: 349076
2018-12-01[ThinLTO] Allow importing of functions with var argsTeresa Johnson1-9/+2
Summary: Follow up to D54270, which allowed importing of var args functions unless they called va_start. As pointed out in the post-commit comments on that patch, the inliner can handle functions that call va_start in certain situations as well. Go ahead and enable importing of all var args functions. Measurements on a large binary show that this increases imports and binary size by an insignificant amount. Reviewers: davidxl Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D54607 llvm-svn: 348068
2018-11-19[ProfileSummary] Standardize methods and fix commentVedant Kumar1-2/+2
Every Analysis pass has a get method that returns a reference of the Result of the Analysis, for example, BlockFrequencyInfo &BlockFrequencyInfoWrapperPass::getBFI(). I believe that ProfileSummaryInfo::getPSI() is the only exception to that, as it was returning a pointer. Another change is renaming isHotBB and isColdBB to isHotBlock and isColdBlock, respectively. Most methods use BB as the argument of variable names while methods usually refer to Basic Blocks as Blocks, instead of BB. For example, Function::getEntryBlock, Loop:getExitBlock, etc. I also fixed one of the comments. Patch by Rodrigo Caetano Rocha! Differential Revision: https://reviews.llvm.org/D54669 llvm-svn: 347182
2018-11-16[ThinLTO] Internalize readonly globalsEugene Leviant1-17/+58
An attempt to recommit r346584 after failure on OSX build bot. Fixed cache key computation in ThinLTOCodeGenerator and added test case llvm-svn: 347033
2018-11-14[ThinLTO] Update handling of vararg functions to match inlinerTeresa Johnson1-2/+7
Summary: Previously we marked all vararg functions as non-inlinable in the function summary, which prevented their importing. However, the corresponding inliner restriction was loosened in r321940/r342675 to only apply to functions calling va_start. Adjust the summary flag computation to match. Reviewers: davidxl Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D54270 llvm-svn: 346883
2018-11-13Revert "[ThinLTO] Internalize readonly globals"Steven Wu1-58/+17
This reverts commit 10c84a8f35cae4a9fc421648d9608fccda3925f2. llvm-svn: 346768
2018-11-10[ThinLTO] Internalize readonly globalsEugene Leviant1-17/+58
This patch allows internalising globals if all accesses to them (from live functions) are from non-volatile load instructions Differential revision: https://reviews.llvm.org/D49362 llvm-svn: 346584
2018-11-06[ThinLTO] Split NotEligibleToImport into legality and inlinability flagsTeresa Johnson1-10/+9
Summary: The NotEligibleToImport flag on the GlobalValueSummary was set if it isn't legal to import (e.g. because it references unpromotable locals) and when it can't be inlined (in which case importing is pointless). I split out the inlinable piece into a separate flag on the FunctionSummary (doesn't make sense for aliases or global variables), because in the future we may want to import for reasons other than inlining. Reviewers: davidxl Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D53345 llvm-svn: 346261
2018-10-12[ThinLTO] Don't import GV which contains blockaddressEugene Leviant1-3/+16
Differential revision: https://reviews.llvm.org/D53139 llvm-svn: 344325
2018-09-27[WPD] Fix incorrect devirtualization after indirect call promotionTeresa Johnson1-11/+12
Summary: Add a dominance check to ensure that the possible devirtualizable call is actually dominated by the type test/checked load intrinsic being analyzed. With PGO, after indirect call promotion is performed during the compile step, followed by inlining, we may have a type test in the promoted and inlined sequence that allows an indirect call in that sequence to be devirtualized. That indirect call (inserted by inlining after promotion) will share the same vtable pointer as the fallback indirect call that cannot be devirtualized. Before this patch the code was incorrectly devirtualizing the fallback indirect call. See the new test and the example described there for more details. Reviewers: pcc, vitalybuka Subscribers: mehdi_amini, Prazek, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D52514 llvm-svn: 343226
2018-06-26[ThinLTO] Add string saver onto index for value namesTeresa Johnson1-2/+2
Summary: Adds a string saver to the ModuleSummaryIndex so it can store value names in the case of adding a ValueInfo for a GUID when we don't have the name stored in a Module string table. This is motivated by the upcoming summary parser patch, where we will read value names from the summary entry and want to store them, even when a Module is not available. Currently this allows us to store the name in the legacy bitcode case, and I have added a test to show that. Reviewers: pcc, dexonsmith Subscribers: mehdi_amini, inglorion, eraman, steven_wu, llvm-commits Differential Revision: https://reviews.llvm.org/D47842 llvm-svn: 335570
2018-06-26[ThinLTO] Compute GUID directly from GV when building per-module indexTeresa Johnson1-6/+6
Summary: I discovered when writing the summary parsing support that the per-module index builder and writer are computing the GUID from the value name alone (ignoring the linkage type). This was ok since those GUID were not emitted in the bitcode, and there are never multiple conflicting names in a single module. However, I don't see a reason for making the GUID computation different for the per-module case. It also makes things simpler on the parsing side to have the GUID computation consistent. So this patch changes the summary analysis phase and the per-module summary writer to compute the GUID using the facility on the GlobalValue. Reviewers: pcc, dexonsmith Subscribers: llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D47844 llvm-svn: 335560
2018-06-06[ThinLTO] Rename index IsAnalysis flag to HaveGVs (NFC)Teresa Johnson1-1/+1
With the upcoming patch to add summary parsing support, IsAnalysis would be true in contexts where we are not performing module summary analysis. Rename to the more specific and approprate HaveGVs, which is essentially what this flag is indicating. llvm-svn: 334140
2018-03-31[ThinLTO] Add an option to force summary call edges cold for debuggingTeresa Johnson1-1/+18
Summary: Useful to selectively disable importing into specific modules for debugging/triaging/workarounds. Reviewers: eraman Subscribers: inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D45062 llvm-svn: 328909
2018-03-13[ThinLTO] Add funtions in callees metadata to CallGraphEdgesTaewook Oh1-0/+12
Summary: If there's a callees metadata attached to the indirect call instruction, add CallGraphEdges to the callees mentioned in the metadata when computing FunctionSummary. * Why this is necessary: Consider following code example: ``` (foo.c) static int f1(int x) {...} static int f2(int x); static int (*fptr)(int) = f2; static int f2(int x) { if (x) fptr=f1; return f1(x); } int foo(int x) { (*fptr)(x); // !callees metadata of !{i32 (i32)* @f1, i32 (i32)* @f2} would be attached to this call. } (bar.c) int bar(int x) { return foo(x); } ``` At LTO time when `foo.o` is imported into `bar.o`, function `foo` might be inlined into `bar` and PGO-guided indirect call promotion will run after that. If the profile data tells that the promotion of `@f1` or `@f2` is beneficial, the optimizer will check if the "promoted" `@f1` or `@f2` (such as `@f1.llvm.0` or `@f2.llvm.0`) is available. Without this patch, importing `!callees` metadata would only add promoted declarations of `@f1` and `@f2` to the `bar.o`, but still the optimizer will assume that the function is available and perform the promotion. The result of that is link failure with `undefined reference to @f1.llvm.0`. This patch fixes this problem by adding callees in the `!callees` metadata to CallGraphEdges so that their definition would be properly imported into. One may ask that there already is a logic to add indirect call promotion targets to be added to CallGraphEdges. However, if profile data says "indirect call promotion is only beneficial under a certain inline context", the logic wouldn't work. In the code example above, if profile data is like ``` bar:1000000:100000 1:100000 1: foo:100000 1: 100000 f1:100000 ``` , Computing FunctionSummary for `foo.o` wouldn't add `foo->f1` to CallGraphEdges. (Also, it is at least "possible" that one can provide profile data to only link step but not to compilation step). Reviewers: tejohnson, mehdi_amini, pcc Reviewed By: tejohnson Subscribers: inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D44399 llvm-svn: 327358
2018-02-22[ThinLTO] Represent relative BF using a scaled representation .Easwaran Raman1-11/+3
Summary: The current integer representation of relative block frequency prevents representing relative block frequencies below 1. This change uses a 8 of the 29 bits to represent the decimal part by using a fixed scale of -8. Reviewers: tejohnson, davidxl Subscribers: mehdi_amini, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D43520 llvm-svn: 325823
2018-01-25Re-land "[ThinLTO] Add call edges' relative block frequency to per-module ↵Easwaran Raman1-3/+18
summary." It was reverted after buildbot regressions. Original commit message: This allows relative block frequency of call edges to be passed to the thinlink stage where it will be used to compute synthetic entry counts of functions. llvm-svn: 323460
2018-01-24Revert "[ThinLTO] Add call edges' relative block frequency to per-module ↵Easwaran Raman1-18/+3
summary." Causes buildbot regressions. llvm-svn: 323358
2018-01-24[ThinLTO] Add call edges' relative block frequency to per-module summary.Easwaran Raman1-3/+18
Summary: This allows relative block frequency of call edges to be passed to the thinlink stage where it will be used to compute synthetic entry counts of functions. Reviewers: tejohnson, pcc Subscribers: mehdi_amini, llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D42212 llvm-svn: 323349
2018-01-22[ThinLTO] Re-commit of dot dumper after test fixEugene Leviant1-1/+1
llvm-svn: 323116
2018-01-21Temporarily revert r323062 to investigate buildbot failuresEugene Leviant1-1/+1
llvm-svn: 323065
2018-01-21[ThinLTO] Implement summary visualizerEugene Leviant1-1/+1
Differential revision: https://reviews.llvm.org/D41297 llvm-svn: 323062
2017-12-25[ThinLTO] Don't import functions with noinline attributeEugene Leviant1-1/+3
Differential revision: https://reviews.llvm.org/D41489 llvm-svn: 321443
2017-12-22Add hasProfileData() to check if a function has profile data. NFC.Easwaran Raman1-1/+1
Summary: This replaces calls to getEntryCount().hasValue() with hasProfileData that does the same thing. This refactoring is useful to do before adding synthetic function entry counts but also a useful cleanup IMO even otherwise. I have used hasProfileData instead of hasRealProfileData as David had earlier suggested since I think profile implies "real" and I use the phrase "synthetic entry count" and not "synthetic profile count" but I am fine calling it hasRealProfileData if you prefer. Reviewers: davidxl, silvas Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41461 llvm-svn: 321331
2017-11-17[ThinLTO] Remove too aggressive assertion in building function call graph.Volodymyr Sapsai1-2/+3
The assertion was introduced in r317853 but there are cases when a call isn't handled either as direct or indirect. In this case we add a reference graph edge but not a call graph edge. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, eraman, hiraditya, efriedma, llvm-commits Differential Revision: https://reviews.llvm.org/D40056 llvm-svn: 318540
2017-11-10[ThinLTO] Fix missing call graph edges for calls with bitcasts.Volodymyr Sapsai1-3/+7
This change doesn't fix the root cause of the miscompile PR34966 as the root cause is in the linker ld64. This change makes call graph more complete allowing to have better module imports/exports. rdar://problem/35344706 Reviewers: tejohnson Reviewed By: tejohnson Subscribers: mehdi_amini, inglorion, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39356 llvm-svn: 317853
2017-11-04[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.Sean Fertile1-4/+5
Now that we have a way to mark GlobalValues as local we can use the symbol resolutions that the linker plugin provides as part of lto/thinlto link step to refine the compilers view on what symbols will end up being local. Originally commited as r317374, but reverted in r317395 to update some missed tests. Differential Revision: https://reviews.llvm.org/D35702 llvm-svn: 317408
2017-11-04Revert "[LTO][ThinLTO] Use the linker resolutions to mark global values ..."Sean Fertile1-5/+4
Changes more tests then expected on one of the build bots. reverting to investigate. This reverts https://llvm.org/svn/llvm-project/llvm/trunk@317374 llvm-svn: 317395
2017-11-03[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.Sean Fertile1-4/+5
Now that we have a way to mark GlobalValues as local we can use the symbol resolutions that the linker plugin provides as part of lto/thinlto link step to refine the compilers view on what symbols will end up being local. Differential Revision: https://reviews.llvm.org/D35702 llvm-svn: 317374
2017-09-13[ThinLTO] AliasSummary should not have any referencesTeresa Johnson1-1/+1
Summary: References should only be on the aliasee. Reviewers: pcc Subscribers: llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D37814 llvm-svn: 313158
2017-09-07ModuleSummaryAnalysis: Correctly handle all function operand references.Peter Collingbourne1-7/+5
The current code that handles personality functions when creating a module summary does not correctly handle the case where a function's personality function operand refers to the function indirectly (e.g. via a bitcast). This patch handles such cases by treating personality function references like any other reference, i.e. by adding them to the function's reference list. This has the minor side benefit of allowing personality functions to participate in early dead stripping. We do this by calling findRefEdges on the function itself. This way we also end up handling other function operands (specifically prefix data and prologue data) for free. Differential Revision: https://reviews.llvm.org/D37553 llvm-svn: 312698
2017-09-01ModuleSummaryAnalysis: Correctly handle refs from function inline asm to ↵Peter Collingbourne1-54/+56
module inline asm. If a function contains inline asm and the module-level inline asm contains the definition of a local symbol, prevent the function from being imported in case the function-level inline asm refers to a symbol in the module-level inline asm. Differential Revision: https://reviews.llvm.org/D37370 llvm-svn: 312332
2017-08-22[lib/Analysis] - Mark personality functions as live.George Rimar1-0/+6
This is PR33245. Case I am fixing is next: Imagine we have 2 BC files, one defines and uses personality routine, second has only declaration and also uses it. Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did not know about personality routines and leaved them dead even if function that has routine was live. As a result thinLTOInternalizeAndPromoteGUID() method changed binding for such symbol to local. Later when LLD tried to link these objects it failed because one object had undefined global symbol for routine and second object contained local definition instead of global. Patch set the live root flag on the corresponding FunctionSummary for personality routines when we build the per-module summaries during the compile step. Differential revision: https://reviews.llvm.org/D36834 llvm-svn: 311432
2017-08-16[Analysis] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-4/+29
other minor fixes (NFC). llvm-svn: 311048
2017-08-04[ThinLTO] Add FunctionAttrs to ThinLTO indexCharles Saternos1-6/+17
Adds function attributes to index: ReadNone, ReadOnly, NoRecurse, NoAlias. This attributes will be used for future ThinLTO optimizations that will propagate function attributes across modules. llvm-svn: 310061
2017-07-07Increase the import-threshold for crtical functions.Dehao Chen1-1/+1
Summary: For interative sample-pgo, if a hot call site is inlined in the profiling binary, we should inline it in before profile annotation in the backend. Before that, the compile phase first collects all GUIDs that needs to be imported and creates virtual "hot" call edge in the summary. However, "hot" is not good enough to guarantee the callsites get inlined. This patch introduces "critical" call edge, and assign much higher importing threshold for those edges. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: sanjoy, mehdi_amini, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D35096 llvm-svn: 307439
2017-06-08Write summaries for merged modules when splitting modules for ThinLTO.Peter Collingbourne1-0/+10
This is to prepare to allow for dead stripping of globals in the merged modules. Differential Revision: https://reviews.llvm.org/D33921 llvm-svn: 305027
2017-06-01(NFC) Track global summary liveness in GVFlags.Evgeniy Stepanov1-6/+6
Replace GVFlags::LiveRoot with GVFlags::Live and use that instead of all the DeadSymbols sets. This is refactoring in order to make liveness information available in the RegularLTO pipeline. llvm-svn: 304466
2017-05-10Ensure non-null ProfileSummaryInfo passed to ModuleSummaryIndex builderTeresa Johnson1-0/+1
This fixes a ubsan bot failure after r302597, which made getProfileCount non-static, but ended up invoking it on a null ProfileSummaryInfo object in some cases from buildModuleSummaryIndex. Most testing passed because the non-static getProfileCount currently doesn't access any member variables, but I found this when testing a follow on patch (D32877) that adds a member variable access. llvm-svn: 302705
2017-05-09[ProfileSummary] Make getProfileCount a non-static member function.Easwaran Raman1-1/+1
This change is required because the notion of count is different for sample profiling and getProfileCount will need to determine the underlying profile type. Differential revision: https://reviews.llvm.org/D33012 llvm-svn: 302597
2017-05-04Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne1-20/+23
the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
2017-05-04Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu1-23/+20
summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. llvm-svn: 302140
2017-05-04IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne1-20/+23
NFCI. When profiling a no-op incremental link of Chromium I found that the functions computeImportForFunction and computeDeadSymbols were consuming roughly 10% of the profile. The goal of this change is to improve the performance of those functions by changing the map lookups that they were previously doing into pointer dereferences. This is achieved by changing the ValueInfo data structure to be a pointer to an element of the global value map owned by ModuleSummaryIndex, and changing reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs. This means that a ValueInfo will take a client directly to the summary list for a given GUID. Differential Revision: https://reviews.llvm.org/D32471 llvm-svn: 302108
2017-05-03Revert r295861, "[ModuleSummaryAnalysis] Don't crash when referencing ↵Peter Collingbourne1-6/+0
unnamed globals." We should always expect values to be named before running the module summary analysis (see NameAnonGlobals pass), so it's fine if we crash in that case. llvm-svn: 301991
2017-03-31ModuleSummaryAnalysis: Use a more precise #include. NFC.Peter Collingbourne1-1/+1
llvm-svn: 299142
2017-03-21Use ProfileSummary:getProfileCount to get ScaledCount for ModuleSummaryDehao Chen1-1/+1
Summary: ModuleSummary should use the standard interface of ProfileSummary::getProfileCount. Reviewers: eraman, tejohnson Reviewed By: tejohnson Subscribers: tejohnson, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D31154 llvm-svn: 298404
2017-03-09Perform symbol binding for .symver versioned symbolsTeresa Johnson1-3/+2
Summary: In a .symver assembler directive like: .symver name, name2@@nodename "name2@@nodename" should get the same symbol binding as "name". While the ELF object writer is updating the symbol binding for .symver aliases before emitting the object file, not doing so when the module inline assembly is handled by the RecordStreamer is causing the wrong behavior in *LTO mode. E.g. when "name" is global, "name2@@nodename" must also be marked as global. Otherwise, the symbol is skipped when iterating over the LTO InputFile symbols (InputFile::Symbol::shouldSkip). So, for example, when performing any *LTO via the gold-plugin, the versioned symbol definition is not recorded by the plugin and passed back to the linker. If the object was in an archive, and there were no other symbols needed from that object, the object would not be included in the final link and references to the versioned symbol are undefined. The llvm-lto2 tests added will give an error about an unused symbol resolution without the fix. Reviewers: rafael, pcc Reviewed By: pcc Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30485 llvm-svn: 297332
2017-02-28Add function importing info from samplepgo profile to the module summary.Dehao Chen1-0/+5
Summary: For SamplePGO, the profile may contain cross-module inline stacks. As we need to make sure the profile annotation happens when all the hot inline stacks are expanded, we need to pass this info to the module importer so that it can import proper functions if necessary. This patch implemented this feature by emitting cross-module targets as part of function entry metadata. In the module-summary phase, the metadata is used to build call edges that points to functions need to be imported. Reviewers: mehdi_amini, tejohnson Reviewed By: tejohnson Subscribers: davidxl, llvm-commits Differential Revision: https://reviews.llvm.org/D30053 llvm-svn: 296498
generated by cgit v1.1 at 2025-09-30 08:18:48 +0000