Changes in ProvenanceAnalysisEvaluator.cpp

feb40a3a - [llvm] Use range-based for loops with instructions (NFC)

Mon, 15 Nov 2021 03:40:48 +0000

[llvm] Use range-based for loops with instructions (NFC) List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

9ed8e0ca - [NFC] Reduce include files dependency and AA header cleanup (part 2).

Wed, 09 Dec 2020 12:06:50 +0000

[NFC] Reduce include files dependency and AA header cleanup (part 2).Continuing work started in https://reviews.llvm.org/D92489:Removed a bunch of includes from "AliasAnalysis.h" and "LoopPassManager.h".Reviewed By: RKSimonDifferential Revision: https://reviews.llvm.org/D92852 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

b0f1d7d5 - Remove unused parameter

Tue, 03 Nov 2020 01:40:06 +0000

Remove unused parameter List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

05da2fe5 - Sink all InitializePasses.h includes

Wed, 13 Nov 2019 21:15:01 +0000

Sink all InitializePasses.h includesThis file lists every pass in LLVM, and is included by Pass.h, which isvery popular. Every time we add, remove, or rename a pass in LLVM, itcaused lots of recompilation.I found this fact by looking at this table, which is sorted by thenumber of times a file was changed over the last 100,000 git commitsmultiplied by the number of object files that depend on it in thecurrent checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.hBefore this change, touching InitializePasses.h would cause 1345 filesto recompile. After this change, touching it only causes 550 compiles inan incremental rebuild.Reviewers: bkramer, asbirlea, bollu, jdoerfertDifferential Revision: https://reviews.llvm.org/D70211 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

2946cd70 - Update the file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 08:50:56 +0000

Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

6bda14b3 - Sort the remaining #include lines in include/... and lib/....

Tue, 06 Jun 2017 11:49:48 +0000

Sort the remaining #include lines in include/... and lib/....I did this a long time ago with a janky python script, but nowclang-format has built-in support for this. I fed clang-format everyline with a #include and let it re-sort things according to the preciseLLVM rules for include ordering baked into clang-format these days.I've reverted a number of files where the results of sorting includesisn't healthy. Either places where we have legacy code relying onparticular include ordering (where possible, I'll fix these separately)or where we have particular formatting around #include lines thatI didn't want to disturb in this patch.This patch is *entirely* mechanical. If you get merge conflicts oranything, just ignore the changes in this patch and run clang-formatover your #include lines in the files.Sorry for any noise here, but it is important to keep these thingsstable. I was seeing an increasing number of patches with irrelevantre-ordering of #include lines because clang-format was used. This patchat least isolates that churn, makes it easy to skip when resolvingconflicts, and gets us to a clean baseline (again).llvm-svn: 304787 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

7b560d40 - [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible

Wed, 09 Sep 2015 17:55:00 +0000

[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatiblewith the new pass manager, and no longer relying on analysis groups.This builds essentially a ground-up new AA infrastructure stack forLLVM. The core ideas are the same that are used throughout the new passmanager: type erased polymorphism and direct composition. The design isas follows:- FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function.- AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure.- All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager.- BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function.All of the references to getting alias analysis results have beenupdated to use the new aggregation interface. All the preservation andother pass management code has been updated accordingly.The way the FunctionAAResultsWrapperPass works is to detect theavailable alias analyses when run, and add them to the results object.This means that we should be able to continue to respect when variouspasses are added to the pipeline, for example adding CFL or adding TBAApasses should just cause their results to be available and to get foldedinto this. The exception to this rule is BasicAA which really needs tobe a function pass due to using dominator trees and loop info. Asa consequence, the FunctionAAResultsWrapperPass directly depends onBasicAA and always includes it in the aggregation.This has significant implications for preserving analyses. Generally,most passes shouldn't bother preserving FunctionAAResultsWrapperPassbecause rebuilding the results just updates the set of known AA passes.The exception to this rule are LoopPass instances which need to preserveall the function analyses that the loop pass manager will end upneeding. This means preserving both BasicAAWrapperPass and theaggregating FunctionAAResultsWrapperPass.Now, when preserving an alias analysis, you do so by directly preservingthat analysis. This is only necessary for non-immutable-pass-providedalias analyses though, and there are only three of interest: BasicAA,GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA ispreserved when needed because it (like DominatorTree and LoopInfo) ismarked as a CFG-only pass. I've expanded GlobalsAA into the preservedset everywhere we previously were preserving all of AliasAnalysis, andI've added SCEVAA in the intersection of that with where we preserveSCEV itself.One significant challenge to all of this is that the CGSCC passes wereactually using the alias analysis implementations by taking advantage ofa pretty amazing set of loop holes in the old pass manager's analysismanagement code which allowed analysis groups to slide through in manycases. Moving away from analysis groups makes this problem much moreobvious. To fix it, I've leveraged the flexibility the design of the newPM components provides to just directly construct the relevant aliasanalyses for the relevant functions in the IPO passes that need them.This is a bit hacky, but should go away with the new pass manager, andis already in many ways cleaner than the prior state.Another significant challenge is that various facilities of the oldalias analysis infrastructure just don't fit any more. The mostsignificant of these is the alias analysis 'counter' pass. That passrelied on the ability to snoop on AA queries at different points in theanalysis group chain. Instead, I'm planning to build printingfunctionality directly into the aggregation layer. I've not includedthat in this patch merely to keep it smaller.Note that all of this needs a nearly complete rewrite of the AAdocumentation. I'm planning to do that, but I'd like to make sure thenew design settles, and to flesh out a bit more of what it looks like inthe new pass manager first.Differential Revision: http://reviews.llvm.org/D12080llvm-svn: 247167 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

a28d91d8 - DataLayout is mandatory, update the API to reflect it with references.

Tue, 10 Mar 2015 02:37:25 +0000

DataLayout is mandatory, update the API to reflect it with references.Summary:Now that the DataLayout is a mandatory part of the module, let's startcleaning the codebase. This patch is a first attempt at doing that.This patch is not exactly NFC as for instance some places were passinga nullptr instead of the DataLayout, possibly just because there was adefault value on the DataLayout argument to many functions in the API.Even though it is not purely NFC, there is no change in thevalidation.I turned as many pointer to DataLayout to references, this helpedfiguring out all the places where a nullptr could come up.I had initially a local version of this patch broken into over 30independant, commits but some later commit were cleaning the API andtouching part of the code modified in the previous commits, so itseemed cleaner without the intermediate state.Test Plan:Reviewers: echristoSubscribers: llvm-commitsFrom: Mehdi Amini llvm-svn: 231740 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

a3b5b607 - Add back r222061 with a fix.

Mon, 17 Nov 2014 02:28:27 +0000

Add back r222061 with a fix.This adds back r222061, but now calls initializePAEvalPass from the correctlibrary to avoid link problems.Original message:Don't make assumptions about the name of private global variables.Private variables are can be renamed, so it is not reliable to makedecisions on the name.The name is also dropped by the assembler before getting to thelinker, so using the name causes a disconnect between how llvm makes adecision (var name) and how the linker makes a decision (section it isin).This patch changes one case where we were looking at the variable name to usethe section instead.Test tuning by Michael Gottesman.llvm-svn: 222117 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp

2fc72309 - Don't make assumptions about the name of private global variables.

Fri, 14 Nov 2014 23:17:47 +0000

Don't make assumptions about the name of private global variables.Private variables are can be renamed, so it is not reliable to makedecisions on the name.The name is also dropped by the assembler before getting to thelinker, so using the name causes a disconnect between how llvm makes adecision (var name) and how the linker makes a decision (section it isin).This patch changes one case where we were looking at the variable name to usethe section instead.Test tuning by Michael Gottesman.llvm-svn: 222061 List of files: /llvm-project-15.0.7/llvm/lib/Transforms/ObjCARC/ProvenanceAnalysisEvaluator.cpp