summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix warning by cl::opt<int> -> cl::opt<unsigned>Vitaly Buka2018-04-061-4/+5
| | | | llvm-svn: 329461
* Runtime flag to control branch funnel thresholdVitaly Buka2018-04-061-2/+6
| | | | | | | | | | Reviewers: pcc Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D45193 llvm-svn: 329459
* Use branch funnels for virtual calls when retpoline mitigation is enabled.Peter Collingbourne2018-03-091-22/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The retpoline mitigation for variant 2 of CVE-2017-5715 inhibits the branch predictor, and as a result it can lead to a measurable loss of performance. We can reduce the performance impact of retpolined virtual calls by replacing them with a special construct known as a branch funnel, which is an instruction sequence that implements virtual calls to a set of known targets using a binary tree of direct branches. This allows the processor to speculately execute valid implementations of the virtual function without allowing for speculative execution of of calls to arbitrary addresses. This patch extends the whole-program devirtualization pass to replace certain virtual calls with calls to branch funnels, which are represented using a new llvm.icall.jumptable intrinsic. It also extends the LowerTypeTests pass to recognize the new intrinsic, generate code for the branch funnels (x86_64 only for now) and lay out virtual tables as required for each branch funnel. The implementation supports full LTO as well as ThinLTO, and extends the ThinLTO summary format used for whole-program devirtualization to support branch funnels. For more details see RFC: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120672.html Differential Revision: https://reviews.llvm.org/D42453 llvm-svn: 327163
* [ThinLTO] Re-commit of dot dumper after test fixEugene Leviant2018-01-221-1/+1
| | | | llvm-svn: 323116
* Temporarily revert r323062 to investigate buildbot failuresEugene Leviant2018-01-211-1/+1
| | | | llvm-svn: 323065
* [ThinLTO] Implement summary visualizerEugene Leviant2018-01-211-1/+1
| | | | | | Differential revision: https://reviews.llvm.org/D41297 llvm-svn: 323062
* WholeProgramDevirt: Simplify ORE getter mechanism for old PM. NFCI.Peter Collingbourne2018-01-051-34/+17
| | | | llvm-svn: 321841
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-0/+1
| | | | llvm-svn: 321114
* Remove redundant includes from lib/Transforms.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320628
* Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet2017-10-091-1/+1
| | | | | | | Sync it up with the name of the class actually defined here. This has been bothering me for a while... llvm-svn: 315249
* WholeProgramDevirt: Add import/export support for targets without absolute ↵Peter Collingbourne2017-09-111-16/+57
| | | | | | | | | | | | | | | | | | | symbol constants. Not all targets support the use of absolute symbols to export constants. In particular, ARM has a wide variety of constant encodings that cannot currently be relocated by linkers. So instead of exporting the constants using symbols, export them directly in the summary. The values of the constants are left as zeroes on targets that support symbolic exports. This may result in more cache misses when targeting those architectures as a result of arbitrary changes in constant values, but this seems somewhat unavoidable for now. Differential Revision: https://reviews.llvm.org/D37407 llvm-svn: 312967
* WholeProgramDevirt: When promoting for single-impl devirt, also rename the ↵Peter Collingbourne2017-09-081-1/+16
| | | | | | | | | | | comdat. This is required when targeting COFF, as the comdat name must match one of the names of the symbols in the comdat. Differential Revision: https://reviews.llvm.org/D37550 llvm-svn: 312767
* WholeProgramDevirt: Create bitcast to i8* at each virtual call site.Peter Collingbourne2017-08-221-5/+6
| | | | | | | | | We can't reuse the llvm.assume instruction's bitcast because it may not dominate every user of the vtable pointer. Differential Revision: https://reviews.llvm.org/D36994 llvm-svn: 311491
* Migrate WholeProgramDevirt to new Optimization Remark APISam Elliott2017-08-211-25/+75
| | | | | | | | | | | | | | | | | Summary: This is an attempt to move WholeProgramDevirt to the new remark API. https://bugs.llvm.org/show_bug.cgi?id=33793 Reviewers: anemet Reviewed By: anemet Subscribers: fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D36943 llvm-svn: 311352
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Re-apply r302108, "IR: Use pointers instead of GUIDs to represent edges in ↵Peter Collingbourne2017-05-041-1/+1
| | | | | | | | the module summary. NFCI." with a fix for the clang backend. llvm-svn: 302176
* Revert "IR: Use pointers instead of GUIDs to represent edges in the module ↵Eric Liu2017-05-041-1/+1
| | | | | | | | | | summary. NFCI." This reverts commit r302108. This causes crash in clang bootstrap with LTO. Contacted the auther in the original commit. llvm-svn: 302140
* IR: Use pointers instead of GUIDs to represent edges in the module summary. ↵Peter Collingbourne2017-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-1/+1
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-1/+1
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-1/+1
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-2/+2
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-2/+2
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* IPO: Const correctness for summaries passed into passes.Peter Collingbourne2017-03-221-24/+36
| | | | | | | | | Pass const qualified summaries into importers and unqualified summaries into exporters. This lets us const-qualify the summary argument to thinBackend. Differential Revision: https://reviews.llvm.org/D31230 llvm-svn: 298534
* IR: Fix a race condition in type id clients of ModuleSummaryIndex.Peter Collingbourne2017-03-221-7/+12
| | | | | | | | | Add a const version of the getTypeIdSummary accessor that avoids mutating the TypeIdMap. Differential Revision: https://reviews.llvm.org/D31226 llvm-svn: 298531
* WholeProgramDevirt: Implement export/import support for VCP.Peter Collingbourne2017-03-101-4/+36
| | | | | | Differential Revision: https://reviews.llvm.org/D30017 llvm-svn: 297503
* WholeProgramDevirt: Implement export/import support for unique ret val opt.Peter Collingbourne2017-03-101-13/+80
| | | | | | Differential Revision: https://reviews.llvm.org/D29917 llvm-svn: 297502
* WholeProgramDevirt: Fixed compilation error under MSVS2015.George Rimar2017-03-101-9/+18
| | | | | | | | | | | | | | | | | | | | | | It was introduced in: r296945 WholeProgramDevirt: Implement exporting for single-impl devirtualization. --------------------- r296939 WholeProgramDevirt: Add any unsuccessful llvm.type.checked.load devirtualizations to the list of llvm.type.test users. --------------------- Microsoft Visual Studio Community 2015 Version 14.0.23107.0 D14REL Does not compile that code without additional brackets, showing multiple error like below: WholeProgramDevirt.cpp(1216): error C2958: the left bracket '[' found at 'c:\access_softek\llvm\lib\transforms\ipo\wholeprogramdevirt.cpp(1216)' was not matched correctly WholeProgramDevirt.cpp(1216): error C2143: syntax error: missing ']' before '}' WholeProgramDevirt.cpp(1216): error C2143: syntax error: missing ';' before '}' WholeProgramDevirt.cpp(1216): error C2059: syntax error: ']' llvm-svn: 297451
* WholeProgramDevirt: Implement importing for uniform ret val opt.Peter Collingbourne2017-03-091-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D29854 llvm-svn: 297350
* WholeProgramDevirt: Implement importing for single-impl devirtualization.Peter Collingbourne2017-03-091-11/+47
| | | | | | Differential Revision: https://reviews.llvm.org/D29844 llvm-svn: 297333
* Fix build.Peter Collingbourne2017-03-041-1/+1
| | | | llvm-svn: 296949
* WholeProgramDevirt: Implement exporting for uniform ret val opt.Peter Collingbourne2017-03-041-6/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D29846 llvm-svn: 296948
* WholeProgramDevirt: Implement exporting for single-impl devirtualization.Peter Collingbourne2017-03-041-6/+54
| | | | | | Differential Revision: https://reviews.llvm.org/D29811 llvm-svn: 296945
* WholeProgramDevirt: Add any unsuccessful llvm.type.checked.load ↵Peter Collingbourne2017-03-041-12/+88
| | | | | | | | | | | | | devirtualizations to the list of llvm.type.test users. Any unsuccessful llvm.type.checked.load devirtualizations will be translated into uses of llvm.type.test, so we need to add the resulting llvm.type.test intrinsics to the function summaries so that the LowerTypeTests pass will export them. Differential Revision: https://reviews.llvm.org/D29808 llvm-svn: 296939
* [OptDiag] Hide legacy remark ctorsAdam Nemet2017-02-231-1/+5
| | | | | | | These are only used when emitting remarks without ORE directly using the free functions emitOptimizationRemark*. llvm-svn: 296037
* OptDiag: Allow constructing DiagnosticLocation from DISubprogramsJustin Bogner2017-02-181-2/+1
| | | | | | | | This avoids creating a DILocation just to represent a line number, since creating Metadata is expensive. Creating a DiagnosticLocation directly is much cheaper. llvm-svn: 295531
* WholeProgramDevirt: For VCP use a 32-bit ConstantInt for the byte offset.Peter Collingbourne2017-02-171-1/+1
| | | | | | | | | | | | | | | A future change will cause this byte offset to be inttoptr'd and then exported via an absolute symbol. On the importing end we will expect the symbol to be in range [0,2^32) so that it will fit into a 32-bit relocation. The problem is that on 64-bit architectures if the offset is negative it will not be in the correct range once we inttoptr it. This change causes us to use a 32-bit integer so that it can be inttoptr'd (which zero extends) into the correct range. Differential Revision: https://reviews.llvm.org/D30016 llvm-svn: 295487
* WholeProgramDevirt: Examine the function body when deciding whether ↵Peter Collingbourne2017-02-171-12/+41
| | | | | | | | | | functions are readnone. The goal is to get an analysis result even for de-refineable functions. Differential Revision: https://reviews.llvm.org/D29803 llvm-svn: 295472
* Re-apply r295110 and r295144 with a fix for the ASan issue.Peter Collingbourne2017-02-151-98/+156
| | | | llvm-svn: 295241
* Revert r295110 and r295144.Daniel Jasper2017-02-151-156/+98
| | | | | | | This fails under ASAN: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/798/steps/check-llvm%20asan/logs/stdio llvm-svn: 295162
* WholeProgramDevirt: Separate the code that applies optzns from the code that ↵Peter Collingbourne2017-02-151-48/+86
| | | | | | | | | | | decides whether to apply them. NFCI. The idea is that the apply* functions will also be called when importing devirt optimizations. Differential Revision: https://reviews.llvm.org/D29745 llvm-svn: 295144
* WholeProgramDevirt: Change internal vcall data structures to match summary.Peter Collingbourne2017-02-141-74/+94
| | | | | | | | | | | | | | | | | | Group calls into constant and non-constant arguments up front, and use uint64_t instead of ConstantInt to represent constant arguments. The goal is to allow the information from the summary to fit naturally into this data structure in a future change (specifically, it will be added to CallSiteInfo). This has two side effects: - We disallow VCP for constant integer arguments of width >64 bits. - We remove the restriction that the bitwidth of a vcall's argument and return types must match those of the vfunc definitions. I don't expect either of these to matter in practice. The first case is uncommon, and the second one will lead to UB (so we can do anything we like). Differential Revision: https://reviews.llvm.org/D29744 llvm-svn: 295110
* IR: Type ID summary extensions for WPD; thread summary into WPD pass.Peter Collingbourne2017-02-131-8/+84
| | | | | | | | | | Make the whole thing testable by adding YAML I/O support for the WPD summary information and adding some negative tests that exercise the YAML support. Differential Revision: https://reviews.llvm.org/D29782 llvm-svn: 294981
* WholeProgramDevirt: Check that VCP candidate functions are defined before ↵Peter Collingbourne2017-02-091-5/+5
| | | | | | | | evaluating them. This was crashing before. llvm-svn: 294666
* WholeProgramDevirt: Teach the pass to handle structs of arrays.Peter Collingbourne2016-12-091-23/+22
| | | | | | This will become necessary in some cases once D22296 lands. llvm-svn: 289165
* Make WholeProgramDevirt understand ConstStruct vtables.Peter Collingbourne2016-12-091-13/+37
| | | | | | | | Based on a patch by LemonBoy! Differential Revision: https://reviews.llvm.org/D26581 llvm-svn: 289162
* Shorten DiagnosticInfoOptimizationRemark* to OptimizationRemark*. NFCAdam Nemet2016-09-271-1/+1
| | | | | | | With the new streaming interface, these class names need to be typed a lot and it's way too looong. llvm-svn: 282544
* WholeProgramDevirt: initialize WasDevirt in all constructors.Ivan Krasin2016-08-121-1/+1
| | | | | | | | Summary: This is a follow up to r278389 and r278442. Differential Revision: https://reviews.llvm.org/D23438 llvm-svn: 278455
* WholeProgramDevirt: generate more detailed and accurate remarks.Ivan Krasin2016-08-111-35/+75
| | | | | | | | | | | | | | | | | | | Summary: Keep track of all methods for which we have devirtualized at least one call and then print them sorted alphabetically. That allows to avoid duplicates and also makes the order deterministic. Add optimization names into the remarks, so that it's easier to understand how has each method been devirtualized. Fix a bug when wrong methods could have been reported for tryVirtualConstProp. Reviewers: kcc, mehdi_amini Differential Revision: https://reviews.llvm.org/D23297 llvm-svn: 278389
* Fix some Clang-tidy modernize and Include What You Use warnings.Eugene Zelenko2016-08-111-8/+28
| | | | | | Differential revision: https://reviews.llvm.org/D23291 llvm-svn: 278364
OpenPOWER on IntegriCloud