maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Analysis/AliasAnalysisEvaluator.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

434 lines
16 KiB
C++
Raw Normal View History

Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
//===- AliasAnalysisEvaluator.cpp - Alias Analysis Accuracy Evaluator -----===//
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
//
Added LLVM project notice to the top of every C++ source file. Header files will be on the way. llvm-svn: 9298
2003-10-21 03:43:21 +08:00
//===----------------------------------------------------------------------===//
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
#include "llvm/Analysis/AliasAnalysisEvaluator.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/ADT/SetVector.h"
#include "llvm/Analysis/AliasAnalysis.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Constants.h"
[PM/AA] Simplify the AliasAnalysis interface by removing a wrapper around a DataLayout interface in favor of directly querying DataLayout. This wrapper specifically helped handle the case where this no DataLayout, but LLVM now requires it simplifynig all of this. I've updated callers to directly query DataLayout. This in turn exposed a bunch of places where we should have DataLayout readily available but don't which I've fixed. This then in turn exposed that we were passing DataLayout around in a bunch of arguments rather than making it readily available so I've also fixed that. No functionality changed. llvm-svn: 244189
2015-08-06 10:05:46 +08:00
#include "llvm/IR/DataLayout.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
[Modules] Move InstIterator out of the Support library, where it had no business. This header includes Function and BasicBlock and directly uses the interfaces of both classes. It has to do with the IR, it even has that in the name. =] Put it in the library it belongs to. This is one step toward making LLVM's Support library survive a C++ modules bootstrap. llvm-svn: 202814
2014-03-04 18:30:26 +08:00
#include "llvm/IR/InstIterator.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Instructions.h"
Sort the remaining #include lines in include/... and lib/.... 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
2017-06-06 19:49:48 +08:00
#include "llvm/IR/Module.h"
Sink all InitializePasses.h includes This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current 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.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
#include "llvm/InitializePasses.h"
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
#include "llvm/Pass.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/Support/CommandLine.h"
Convert debug messages to use dbgs(). Generally this means s/errs/dbgs/g except for certain special cases. llvm-svn: 92026
2009-12-24 03:21:19 +08:00
#include "llvm/Support/Debug.h"
More migration to raw_ostream, the water has dried up around the iostream hole. - Some clients which used DOUT have moved to DEBUG. We are deprecating the "magic" DOUT behavior which avoided calling printing functions when the statement was disabled. In addition to being unnecessary magic, it had the downside of leaving code in -Asserts builds, and of hiding potentially unnecessary computations. llvm-svn: 77019
2009-07-25 08:23:56 +08:00
#include "llvm/Support/raw_ostream.h"
Finegrainify namespacification Provide a context module to WriteAsOperand llvm-svn: 10366
2003-12-10 23:33:59 +08:00
using namespace llvm;
Put all LLVM code into the llvm namespace, as per bug 109. llvm-svn: 9903
2003-11-12 06:41:34 +08:00
Clean up the use of static and anonymous namespaces. This turned up several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
2008-05-13 08:00:25 +08:00
static cl::opt<bool> PrintAll("print-all-alias-modref-info", cl::ReallyHidden);
Cleanups: fold two loops into one New features: -print-all-alias-modref-info option, print more info llvm-svn: 14906
2004-07-17 14:28:49 +08:00
Clean up the use of static and anonymous namespaces. This turned up several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
2008-05-13 08:00:25 +08:00
static cl::opt<bool> PrintNoAlias("print-no-aliases", cl::ReallyHidden);
static cl::opt<bool> PrintMayAlias("print-may-aliases", cl::ReallyHidden);
Teach AliasAnalysisEvaluator about PartialAlias. llvm-svn: 121512
2010-12-11 03:52:40 +08:00
static cl::opt<bool> PrintPartialAlias("print-partial-aliases", cl::ReallyHidden);
Clean up the use of static and anonymous namespaces. This turned up several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
2008-05-13 08:00:25 +08:00
static cl::opt<bool> PrintMustAlias("print-must-aliases", cl::ReallyHidden);
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
Clean up the use of static and anonymous namespaces. This turned up several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
2008-05-13 08:00:25 +08:00
static cl::opt<bool> PrintNoModRef("print-no-modref", cl::ReallyHidden);
static cl::opt<bool> PrintRef("print-ref", cl::ReallyHidden);
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
static cl::opt<bool> PrintMod("print-mod", cl::ReallyHidden);
Clean up the use of static and anonymous namespaces. This turned up several things that were neither in an anonymous namespace nor static but not intended to be global. llvm-svn: 51017
2008-05-13 08:00:25 +08:00
static cl::opt<bool> PrintModRef("print-modref", cl::ReallyHidden);
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
static cl::opt<bool> PrintMust("print-must", cl::ReallyHidden);
static cl::opt<bool> PrintMustRef("print-mustref", cl::ReallyHidden);
static cl::opt<bool> PrintMustMod("print-mustmod", cl::ReallyHidden);
static cl::opt<bool> PrintMustModRef("print-mustmodref", cl::ReallyHidden);
Allow printing of various types of alias analysis results llvm-svn: 5520
2003-02-10 04:40:13 +08:00
AA metadata refactoring (introduce AAMDNodes) In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
2014-07-24 20:16:19 +08:00
static cl::opt<bool> EvalAAMD("evaluate-aa-metadata", cl::ReallyHidden);
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
static void PrintResults(AliasResult AR, bool P, const Value *V1,
eliminate the std::ostream form of WriteAsOperand and update clients. This also updates dominator related stuff. llvm-svn: 79825
2009-08-23 13:17:37 +08:00
const Value *V2, const Module *M) {
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
if (PrintAll || P) {
eliminate the std::ostream form of WriteAsOperand and update clients. This also updates dominator related stuff. llvm-svn: 79825
2009-08-23 13:17:37 +08:00
std::string o1, o2;
{
raw_string_ostream os1(o1), os2(o2);
Put the functionality for printing a value to a raw_ostream as an operand into the Value interface just like the core print method is. That gives a more conistent organization to the IR printing interfaces -- they are all attached to the IR objects themselves. Also, update all the users. This removes the 'Writer.h' header which contained only a single function declaration. llvm-svn: 198836
2014-01-09 10:29:41 +08:00
V1->printAsOperand(os1, true, M);
V2->printAsOperand(os2, true, M);
eliminate the std::ostream form of WriteAsOperand and update clients. This also updates dominator related stuff. llvm-svn: 79825
2009-08-23 13:17:37 +08:00
}
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
Fix http://llvm.org/bugs/show_bug.cgi?id=2104 by ordering lexicographically what gets printed. Be const-correct in PrintResults and uninline it too llvm-svn: 47712
2008-02-28 16:38:45 +08:00
if (o2 < o1)
More migration to raw_ostream, the water has dried up around the iostream hole. - Some clients which used DOUT have moved to DEBUG. We are deprecating the "magic" DOUT behavior which avoided calling printing functions when the statement was disabled. In addition to being unnecessary magic, it had the downside of leaving code in -Asserts builds, and of hiding potentially unnecessary computations. llvm-svn: 77019
2009-07-25 08:23:56 +08:00
std::swap(o1, o2);
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
errs() << " " << AR << ":\t" << o1 << ", " << o2 << "\n";
Allow printing of various types of alias analysis results llvm-svn: 5520
2003-02-10 04:40:13 +08:00
}
}
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
static inline void PrintModRefResults(const char *Msg, bool P, Instruction *I,
Value *Ptr, Module *M) {
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
if (PrintAll || P) {
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " " << Msg << ": Ptr: ";
Put the functionality for printing a value to a raw_ostream as an operand into the Value interface just like the core print method is. That gives a more conistent organization to the IR printing interfaces -- they are all attached to the IR objects themselves. Also, update all the users. This removes the 'Writer.h' header which contained only a single function declaration. llvm-svn: 198836
2014-01-09 10:29:41 +08:00
Ptr->printAsOperand(errs(), true, M);
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << "\t<->" << *I << '\n';
Print modref information in a useful way. llvm-svn: 14907
2004-07-17 14:43:20 +08:00
}
}
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
static inline void PrintModRefResults(const char *Msg, bool P, CallBase *CallA,
CallBase *CallB, Module *M) {
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
if (PrintAll || P) {
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
errs() << " " << Msg << ": " << *CallA << " <-> " << *CallB << '\n';
The two-callsite form of AliasAnalysis::getModRefInfo is documented to return Ref if the left callsite only reads memory read or written by the right callsite; fix BasicAliasAnalysis to implement this. Add AliasAnalysisEvaluator support for testing the two-callsite form of getModRefInfo. llvm-svn: 110270
2010-08-05 06:56:29 +08:00
}
}
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
static inline void PrintLoadStoreResults(AliasResult AR, bool P,
const Value *V1, const Value *V2,
const Module *M) {
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
if (PrintAll || P) {
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
errs() << " " << AR << ": " << *V1 << " <-> " << *V2 << '\n';
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
}
}
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
static inline bool isInterestingPointer(Value *V) {
return V->getType()->isPointerTy()
&& !isa<ConstantPointerNull>(V);
}
Consistently use FunctionAnalysisManager Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
2016-08-09 08:28:15 +08:00
PreservedAnalyses AAEvaluator::run(Function &F, FunctionAnalysisManager &AM) {
[PM] Make the AnalysisManager parameter to run methods a reference. This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
2016-03-11 19:05:24 +08:00
runInternal(F, AM.getResult<AAManager>(F));
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
return PreservedAnalyses::all();
}
void AAEvaluator::runInternal(Function &F, AAResults &AA) {
[PM/AA] Simplify the AliasAnalysis interface by removing a wrapper around a DataLayout interface in favor of directly querying DataLayout. This wrapper specifically helped handle the case where this no DataLayout, but LLVM now requires it simplifynig all of this. I've updated callers to directly query DataLayout. This in turn exposed a bunch of places where we should have DataLayout readily available but don't which I've fixed. This then in turn exposed that we were passing DataLayout around in a bunch of arguments rather than making it readily available so I've also fixed that. No functionality changed. llvm-svn: 244189
2015-08-06 10:05:46 +08:00
const DataLayout &DL = F.getParent()->getDataLayout();
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
++FunctionCount;
Remove interprocedural-basic-aa and associated code. The AliasAnalysis interface needs implementations to be consistent, so any code which wants to support different semantics must use a different interface. It's not currently worthwhile to add a new interface for this new concept. Document that AliasAnalysis doesn't support cross-function queries. llvm-svn: 107776
2010-07-07 22:27:09 +08:00
SetVector<Value *> Pointers;
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
SmallSetVector<CallBase *, 16> Calls;
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
SetVector<Value *> Loads;
SetVector<Value *> Stores;
Remove interprocedural-basic-aa and associated code. The AliasAnalysis interface needs implementations to be consistent, so any code which wants to support different semantics must use a different interface. It's not currently worthwhile to add a new interface for this new concept. Document that AliasAnalysis doesn't support cross-function queries. llvm-svn: 107776
2010-07-07 22:27:09 +08:00
Analysis: Remove implicit ilist iterator conversions Remove implicit ilist iterator conversions from LLVMAnalysis. I came across something really scary in `llvm::isKnownNotFullPoison()` which relied on `Instruction::getNextNode()` being completely broken (not surprising, but scary nevertheless). This function is documented (and coded to) return `nullptr` when it gets to the sentinel, but with an `ilist_half_node` as a sentinel, the sentinel check looks into some other memory and we don't recognize we've hit the end. Rooting out these scary cases is the reason I'm removing the implicit conversions before doing anything else with `ilist`; I'm not at all surprised that clients rely on badness. I found another scary case -- this time, not relying on badness, just bad (but I guess getting lucky so far) -- in `ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the insertion point, do some things, and then restore it. Previously, we let the iterator auto-convert to `Instruction*`, and then set it back using the `Instruction*` version: Instruction *PrevInsertPoint = Builder.GetInsertPoint(); /* Logic that may change insert point */ if (PrevInsertPoint) Builder.SetInsertPoint(PrevInsertPoint); The check for `PrevInsertPoint` doesn't protect correctly against bad accesses. If the insertion point has been set to the end of a basic block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns an iterator pointing at the list sentinel. The version of `SetInsertPoint()` that's getting called will then call `PrevInsertPoint->getParent()`, which explodes horribly. The only reason this hasn't blown up is that it's fairly unlikely the builder is adding to the end of the block; usually, we're adding instructions somewhere before the terminator. llvm-svn: 249925
2015-10-10 08:53:03 +08:00
for (auto &I : F.args())
if (I.getType()->isPointerTy()) // Add all pointer arguments.
Pointers.insert(&I);
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
[Analysis] Use range-based for loops (NFC)
2021-02-07 03:17:09 +08:00
for (Instruction &Inst : instructions(F)) {
if (Inst.getType()->isPointerTy()) // Add all pointer instructions.
Pointers.insert(&Inst);
if (EvalAAMD && isa<LoadInst>(&Inst))
Loads.insert(&Inst);
if (EvalAAMD && isa<StoreInst>(&Inst))
Stores.insert(&Inst);
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
if (auto *Call = dyn_cast<CallBase>(&Inst)) {
[IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand(). This method has been commented as deprecated for a while. Remove it and replace all uses with the equivalent getCalledOperand(). I also made a few cleanups in here. For example, to removes use of getElementType on a pointer when we could just use getFunctionType from the call. Differential Revision: https://reviews.llvm.org/D78882
2020-04-28 11:15:59 +08:00
Value *Callee = Call->getCalledOperand();
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
// Skip actual functions for direct function calls.
if (!isa<Function>(Callee) && isInterestingPointer(Callee))
Pointers.insert(Callee);
// Consider formals.
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
for (Use &DataOp : Call->data_ops())
[OperandBundles] Have GlobalsModRef play nice with operand bundles A call site's use of a Value might not correspond to an argument operand but to a bundle operand. llvm-svn: 256329
2015-12-23 17:58:46 +08:00
if (isInterestingPointer(DataOp))
Pointers.insert(DataOp);
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
Calls.insert(Call);
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
} else {
// Consider all operands.
[Analysis] Use range-based for loops (NFC)
2021-02-07 03:17:09 +08:00
for (Use &Op : Inst.operands())
if (isInterestingPointer(Op))
Pointers.insert(Op);
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
}
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
}
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
if (PrintAll || PrintNoAlias || PrintMayAlias || PrintPartialAlias ||
PrintMustAlias || PrintNoModRef || PrintMod || PrintRef || PrintModRef)
Remove interprocedural-basic-aa and associated code. The AliasAnalysis interface needs implementations to be consistent, so any code which wants to support different semantics must use a different interface. It's not currently worthwhile to add a new interface for this new concept. Document that AliasAnalysis doesn't support cross-function queries. llvm-svn: 107776
2010-07-07 22:27:09 +08:00
errs() << "Function: " << F.getName() << ": " << Pointers.size()
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
<< " pointers, " << Calls.size() << " call sites\n";
Allow printing of various types of alias analysis results llvm-svn: 5520
2003-02-10 04:40:13 +08:00
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
// iterate over the worklist, and run the full (n^2)/2 disambiguations
Use SetVector instead of std::set so that alias relations are tested and printed in a deterministic order. llvm-svn: 80095
2009-08-26 22:32:17 +08:00
for (SetVector<Value *>::iterator I1 = Pointers.begin(), E = Pointers.end();
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
I1 != E; ++I1) {
[AA] Split up LocationSize::unknown() Currently, we have some confusion in the codebase regarding the meaning of LocationSize::unknown(): Some parts (including most of BasicAA) assume that LocationSize::unknown() only allows accesses after the base pointer. Some parts (various callers of AA) assume that LocationSize::unknown() allows accesses both before and after the base pointer (but within the underlying object). This patch splits up LocationSize::unknown() into LocationSize::afterPointer() and LocationSize::beforeOrAfterPointer() to make this completely unambiguous. I tried my best to determine which one is appropriate for all the existing uses. The test changes in cs-cs.ll in particular illustrate a previously clearly incorrect AA result: We were effectively assuming that argmemonly functions were only allowed to access their arguments after the passed pointer, but not before it. I'm pretty sure that this was not intentional, and it's certainly not specified by LangRef that way. Differential Revision: https://reviews.llvm.org/D91649
2020-11-18 03:11:09 +08:00
auto I1Size = LocationSize::afterPointer();
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Type *I1ElTy = cast<PointerType>((*I1)->getType())->getElementType();
[AAEval] Use LocationSize instead of ints; NFC Keeping these patches super small so they're easily post-commit verifiable, as requested in D44748. llvm-svn: 350014
2018-12-23 10:39:58 +08:00
if (I1ElTy->isSized())
I1Size = LocationSize::precise(DL.getTypeStoreSize(I1ElTy));
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
Use SetVector instead of std::set so that alias relations are tested and printed in a deterministic order. llvm-svn: 80095
2009-08-26 22:32:17 +08:00
for (SetVector<Value *>::iterator I2 = Pointers.begin(); I2 != I1; ++I2) {
[AA] Split up LocationSize::unknown() Currently, we have some confusion in the codebase regarding the meaning of LocationSize::unknown(): Some parts (including most of BasicAA) assume that LocationSize::unknown() only allows accesses after the base pointer. Some parts (various callers of AA) assume that LocationSize::unknown() allows accesses both before and after the base pointer (but within the underlying object). This patch splits up LocationSize::unknown() into LocationSize::afterPointer() and LocationSize::beforeOrAfterPointer() to make this completely unambiguous. I tried my best to determine which one is appropriate for all the existing uses. The test changes in cs-cs.ll in particular illustrate a previously clearly incorrect AA result: We were effectively assuming that argmemonly functions were only allowed to access their arguments after the passed pointer, but not before it. I'm pretty sure that this was not intentional, and it's certainly not specified by LangRef that way. Differential Revision: https://reviews.llvm.org/D91649
2020-11-18 03:11:09 +08:00
auto I2Size = LocationSize::afterPointer();
[AAEval] Use LocationSize instead of ints; NFC Keeping these patches super small so they're easily post-commit verifiable, as requested in D44748. llvm-svn: 350014
2018-12-23 10:39:58 +08:00
Type *I2ElTy = cast<PointerType>((*I2)->getType())->getElementType();
if (I2ElTy->isSized())
I2Size = LocationSize::precise(DL.getTypeStoreSize(I2ElTy));
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
AliasResult AR = AA.alias(*I1, I1Size, *I2, I2Size);
switch (AR) {
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case NoAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintResults(AR, PrintNoAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++NoAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MayAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintResults(AR, PrintMayAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MayAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case PartialAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintResults(AR, PrintPartialAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++PartialAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MustAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintResults(AR, PrintMustAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MustAliasCount;
break;
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
}
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
}
}
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
AA metadata refactoring (introduce AAMDNodes) In order to enable the preservation of noalias function parameter information after inlining, and the representation of block-level __restrict__ pointer information (etc.), additional kinds of aliasing metadata will be introduced. This metadata needs to be carried around in AliasAnalysis::Location objects (and MMOs at the SDAG level), and so we need to generalize the current scheme (which is hard-coded to just one TBAA MDNode*). This commit introduces only the necessary refactoring to allow for the introduction of other aliasing metadata types, but does not actually introduce any (that will come in a follow-up commit). What it does introduce is a new AAMDNodes structure to hold all of the aliasing metadata nodes associated with a particular memory-accessing instruction, and uses that structure instead of the raw MDNode* in AliasAnalysis::Location, etc. No functionality change intended. llvm-svn: 213859
2014-07-24 20:16:19 +08:00
if (EvalAAMD) {
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
// iterate over all pairs of load, store
Apply clang-tidy's modernize-loop-convert to lib/Analysis. Only minor manual fixes. No functionality change intended. llvm-svn: 273816
2016-06-27 01:27:42 +08:00
for (Value *Load : Loads) {
for (Value *Store : Stores) {
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
AliasResult AR = AA.alias(MemoryLocation::get(cast<LoadInst>(Load)),
MemoryLocation::get(cast<StoreInst>(Store)));
switch (AR) {
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case NoAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintNoAlias, Load, Store, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++NoAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MayAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintMayAlias, Load, Store, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MayAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case PartialAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintPartialAlias, Load, Store, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++PartialAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MustAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintMustAlias, Load, Store, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MustAliasCount;
break;
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
}
}
}
// iterate over all pairs of store, store
for (SetVector<Value *>::iterator I1 = Stores.begin(), E = Stores.end();
I1 != E; ++I1) {
for (SetVector<Value *>::iterator I2 = Stores.begin(); I2 != I1; ++I2) {
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
AliasResult AR = AA.alias(MemoryLocation::get(cast<StoreInst>(*I1)),
MemoryLocation::get(cast<StoreInst>(*I2)));
switch (AR) {
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case NoAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintNoAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++NoAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MayAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintMayAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MayAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case PartialAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintPartialAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++PartialAliasCount;
break;
[PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class. This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
2015-06-22 10:16:51 +08:00
case MustAlias:
[MSSA] Print more optimization information In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
2018-06-15 03:55:53 +08:00
PrintLoadStoreResults(AR, PrintMustAlias, *I1, *I2, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++MustAliasCount;
break;
Support in AAEvaluator to print alias queries of loads/stores with TBAA tags. Add "evaluate-tbaa" to print alias queries of loads/stores. Alias queries between pointers do not include TBAA tags. Add testing case for "placement new". TBAA currently says NoAlias. llvm-svn: 177772
2013-03-23 06:34:41 +08:00
}
}
}
}
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
// Mod/ref alias analysis: compare all pairs of calls and values
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
for (CallBase *Call : Calls) {
Apply clang-tidy's modernize-loop-convert to lib/Analysis. Only minor manual fixes. No functionality change intended. llvm-svn: 273816
2016-06-27 01:27:42 +08:00
for (auto Pointer : Pointers) {
[AA] Split up LocationSize::unknown() Currently, we have some confusion in the codebase regarding the meaning of LocationSize::unknown(): Some parts (including most of BasicAA) assume that LocationSize::unknown() only allows accesses after the base pointer. Some parts (various callers of AA) assume that LocationSize::unknown() allows accesses both before and after the base pointer (but within the underlying object). This patch splits up LocationSize::unknown() into LocationSize::afterPointer() and LocationSize::beforeOrAfterPointer() to make this completely unambiguous. I tried my best to determine which one is appropriate for all the existing uses. The test changes in cs-cs.ll in particular illustrate a previously clearly incorrect AA result: We were effectively assuming that argmemonly functions were only allowed to access their arguments after the passed pointer, but not before it. I'm pretty sure that this was not intentional, and it's certainly not specified by LangRef that way. Differential Revision: https://reviews.llvm.org/D91649
2020-11-18 03:11:09 +08:00
auto Size = LocationSize::afterPointer();
Apply clang-tidy's modernize-loop-convert to lib/Analysis. Only minor manual fixes. No functionality change intended. llvm-svn: 273816
2016-06-27 01:27:42 +08:00
Type *ElTy = cast<PointerType>(Pointer->getType())->getElementType();
[AAEval] Use LocationSize instead of ints; NFC Keeping these patches super small so they're easily post-commit verifiable, as requested in D44748. llvm-svn: 350014
2018-12-23 10:39:58 +08:00
if (ElTy->isSized())
Size = LocationSize::precise(DL.getTypeStoreSize(ElTy));
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
switch (AA.getModRefInfo(Call, Pointer, Size)) {
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::NoModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("NoModRef", PrintNoModRef, Call, Pointer,
Apply clang-tidy's modernize-loop-convert to lib/Analysis. Only minor manual fixes. No functionality change intended. llvm-svn: 273816
2016-06-27 01:27:42 +08:00
F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++NoModRefCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::Mod:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Mod", PrintMod, Call, Pointer, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++ModCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::Ref:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Ref", PrintRef, Call, Pointer, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++RefCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::ModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Both ModRef", PrintModRef, Call, Pointer,
Apply clang-tidy's modernize-loop-convert to lib/Analysis. Only minor manual fixes. No functionality change intended. llvm-svn: 273816
2016-06-27 01:27:42 +08:00
F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++ModRefCount;
break;
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
case ModRefInfo::Must:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Must", PrintMust, Call, Pointer, F.getParent());
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
++MustCount;
break;
case ModRefInfo::MustMod:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Mod (MustAlias)", PrintMustMod, Call, Pointer,
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
F.getParent());
++MustModCount;
break;
case ModRefInfo::MustRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Ref (MustAlias)", PrintMustRef, Call, Pointer,
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
F.getParent());
++MustRefCount;
break;
case ModRefInfo::MustModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Both ModRef (MustAlias)", PrintMustModRef, Call,
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
Pointer, F.getParent());
++MustModRefCount;
break;
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
}
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
}
Fix incorrect computation of mod/ref sets. Do not ask for mod/ref information for objects of size 0. llvm-svn: 14908
2004-07-17 15:40:34 +08:00
}
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
The two-callsite form of AliasAnalysis::getModRefInfo is documented to return Ref if the left callsite only reads memory read or written by the right callsite; fix BasicAliasAnalysis to implement this. Add AliasAnalysisEvaluator support for testing the two-callsite form of getModRefInfo. llvm-svn: 110270
2010-08-05 06:56:29 +08:00
// Mod/ref alias analysis: compare all pairs of calls
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
for (CallBase *CallA : Calls) {
for (CallBase *CallB : Calls) {
if (CallA == CallB)
The two-callsite form of AliasAnalysis::getModRefInfo is documented to return Ref if the left callsite only reads memory read or written by the right callsite; fix BasicAliasAnalysis to implement this. Add AliasAnalysisEvaluator support for testing the two-callsite form of getModRefInfo. llvm-svn: 110270
2010-08-05 06:56:29 +08:00
continue;
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
switch (AA.getModRefInfo(CallA, CallB)) {
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::NoModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("NoModRef", PrintNoModRef, CallA, CallB,
F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++NoModRefCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::Mod:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Mod", PrintMod, CallA, CallB, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++ModCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::Ref:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Ref", PrintRef, CallA, CallB, F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++RefCount;
break;
[ModRefInfo] Make enum ModRefInfo an enum class [NFC]. Summary: Make enum ModRefInfo an enum class. Changes to ModRefInfo values should be done using inline wrappers. This should prevent future bit-wise opearations from being added, which can be more error-prone. Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40933 llvm-svn: 320107
2017-12-08 06:41:34 +08:00
case ModRefInfo::ModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Both ModRef", PrintModRef, CallA, CallB,
F.getParent());
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
++ModRefCount;
break;
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
case ModRefInfo::Must:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Must", PrintMust, CallA, CallB, F.getParent());
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
++MustCount;
break;
case ModRefInfo::MustMod:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Mod (MustAlias)", PrintMustMod, CallA, CallB,
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
F.getParent());
++MustModCount;
break;
case ModRefInfo::MustRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Just Ref (MustAlias)", PrintMustRef, CallA, CallB,
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
F.getParent());
++MustRefCount;
break;
case ModRefInfo::MustModRef:
[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper. This moves the largest interwoven collection of APIs that traffic in `CallSite`s. While a handful of these could have been migrated with a minorly more shallow migration by converting from a `CallSite` to a `CallBase`, it hardly seemed worth it. Most of the APIs needed to migrate together because of the complex interplay of AA APIs and the fact that converting from a `CallBase` to a `CallSite` isn't free in its current implementation. Out of tree users of these APIs can fairly reliably migrate with some combination of `.getInstruction()` on the `CallSite` instance and casting the resulting pointer. The most generic form will look like `CS` -> `cast_or_null<CallBase>(CS.getInstruction())` but in most cases there is a more elegant migration. Hopefully, this migrates enough APIs for users to fully move from `CallSite` to the base class. All of the in-tree users were easily migrated in that fashion. Thanks for the review from Saleem! Differential Revision: https://reviews.llvm.org/D55641 llvm-svn: 350503
2019-01-07 13:42:51 +08:00
PrintModRefResults("Both ModRef (MustAlias)", PrintMustModRef, CallA,
CallB, F.getParent());
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
++MustModRefCount;
break;
The two-callsite form of AliasAnalysis::getModRefInfo is documented to return Ref if the left callsite only reads memory read or written by the right callsite; fix BasicAliasAnalysis to implement this. Add AliasAnalysisEvaluator support for testing the two-callsite form of getModRefInfo. llvm-svn: 110270
2010-08-05 06:56:29 +08:00
}
}
}
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
}
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
static void PrintPercent(int64_t Num, int64_t Sum) {
errs() << "(" << Num * 100LL / Sum << "." << ((Num * 1000LL / Sum) % 10)
<< "%)\n";
Factor out percentage printing into its own function. Make two changes to the function: print more precision XX.X% instead of XX%, and cast to ULL before scaling by 100/1000 to avoid wrap around for large numbers of queries (such as occur for 253.perlbmk and 176.gcc) llvm-svn: 20872
2005-03-27 07:56:33 +08:00
}
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
AAEvaluator::~AAEvaluator() {
if (FunctionCount == 0)
return;
int64_t AliasSum =
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
NoAliasCount + MayAliasCount + PartialAliasCount + MustAliasCount;
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << "===== Alias Analysis Evaluator Report =====\n";
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
if (AliasSum == 0) {
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " Alias Analysis Evaluator Summary: No pointers!\n";
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
} else {
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " " << AliasSum << " Total Alias Queries Performed\n";
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
errs() << " " << NoAliasCount << " no alias responses ";
PrintPercent(NoAliasCount, AliasSum);
errs() << " " << MayAliasCount << " may alias responses ";
PrintPercent(MayAliasCount, AliasSum);
errs() << " " << PartialAliasCount << " partial alias responses ";
PrintPercent(PartialAliasCount, AliasSum);
errs() << " " << MustAliasCount << " must alias responses ";
PrintPercent(MustAliasCount, AliasSum);
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " Alias Analysis Evaluator Pointer Alias Summary: "
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
<< NoAliasCount * 100 / AliasSum << "%/"
<< MayAliasCount * 100 / AliasSum << "%/"
<< PartialAliasCount * 100 / AliasSum << "%/"
<< MustAliasCount * 100 / AliasSum << "%\n";
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
}
// Display the summary for mod/ref analysis
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
int64_t ModRefSum = NoModRefCount + RefCount + ModCount + ModRefCount +
MustCount + MustRefCount + MustModCount + MustModRefCount;
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
if (ModRefSum == 0) {
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
errs() << " Alias Analysis Mod/Ref Evaluator Summary: no "
"mod/ref!\n";
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
} else {
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " " << ModRefSum << " Total ModRef Queries Performed\n";
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
errs() << " " << NoModRefCount << " no mod/ref responses ";
PrintPercent(NoModRefCount, ModRefSum);
errs() << " " << ModCount << " mod responses ";
PrintPercent(ModCount, ModRefSum);
errs() << " " << RefCount << " ref responses ";
PrintPercent(RefCount, ModRefSum);
errs() << " " << ModRefCount << " mod & ref responses ";
PrintPercent(ModRefCount, ModRefSum);
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
errs() << " " << MustCount << " must responses ";
PrintPercent(MustCount, ModRefSum);
errs() << " " << MustModCount << " must mod responses ";
PrintPercent(MustModCount, ModRefSum);
errs() << " " << MustRefCount << " must ref responses ";
PrintPercent(MustRefCount, ModRefSum);
errs() << " " << MustModRefCount << " must mod & ref responses ";
PrintPercent(MustModRefCount, ModRefSum);
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " Alias Analysis Evaluator Mod/Ref Summary: "
[PM/AA] Suffix lots of member variables that directly use enumeration names for counts with the word 'Count' to make them less ambiguous. This will be an actual error if we use unscoped enums for any of these, and generally this seems much clearer to read. Also, use clang-format to normalize the formatting of this code which seems to have been needlessly odd. No functionality changed here. llvm-svn: 239887
2015-06-17 15:21:41 +08:00
<< NoModRefCount * 100 / ModRefSum << "%/"
<< ModCount * 100 / ModRefSum << "%/" << RefCount * 100 / ModRefSum
[ModRefInfo] Add must alias info to ModRefInfo. Summary: Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases. Shift existing Mod/Ref/ModRef values to include an additional most significant bit. Update wrappers that modify ModRefInfo values to reflect the change. Notes: * ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it. * Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA). * GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost. * There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location. Reviewers: dberlin, hfinkel, george.burgess.iv Subscribers: llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D38862 llvm-svn: 321309
2017-12-22 05:41:53 +08:00
<< "%/" << ModRefCount * 100 / ModRefSum << "%/"
<< MustCount * 100 / ModRefSum << "%/"
<< MustRefCount * 100 / ModRefSum << "%/"
<< MustModCount * 100 / ModRefSum << "%/"
<< MustModRefCount * 100 / ModRefSum << "%\n";
Fix division by zero problem llvm-svn: 5509
2003-02-09 07:04:50 +08:00
}
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
}
namespace llvm {
class AAEvalLegacyPass : public FunctionPass {
std::unique_ptr<AAEvaluator> P;
public:
static char ID; // Pass identification, replacement for typeid
AAEvalLegacyPass() : FunctionPass(ID) {
initializeAAEvalLegacyPassPass(*PassRegistry::getPassRegistry());
}
Remove interprocedural-basic-aa and associated code. The AliasAnalysis interface needs implementations to be consistent, so any code which wants to support different semantics must use a different interface. It's not currently worthwhile to add a new interface for this new concept. Document that AliasAnalysis doesn't support cross-function queries. llvm-svn: 107776
2010-07-07 22:27:09 +08:00
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
void getAnalysisUsage(AnalysisUsage &AU) const override {
AU.addRequired<AAResultsWrapperPass>();
AU.setPreservesAll();
}
bool doInitialization(Module &M) override {
P.reset(new AAEvaluator());
return false;
}
bool runOnFunction(Function &F) override {
P->runInternal(F, getAnalysis<AAResultsWrapperPass>().getAAResults());
return false;
}
bool doFinalization(Module &M) override {
P.reset();
return false;
}
};
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
}
[PM/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
char AAEvalLegacyPass::ID = 0;
INITIALIZE_PASS_BEGIN(AAEvalLegacyPass, "aa-eval",
"Exhaustive Alias Analysis Precision Evaluator", false,
true)
INITIALIZE_PASS_DEPENDENCY(AAResultsWrapperPass)
INITIALIZE_PASS_END(AAEvalLegacyPass, "aa-eval",
"Exhaustive Alias Analysis Precision Evaluator", false,
true)
FunctionPass *llvm::createAAEvalPass() { return new AAEvalLegacyPass(); }