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

396 lines
14 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
//
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
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
2007-12-30 04:36:04 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
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
//
// This file implements a simple N^2 alias analysis accuracy evaluator.
// Basically, for each function in the program, it simply queries to see how the
// alias analysis implementation answers alias queries between each pair of
// pointers in the function.
//
// This is inspired and adapted from code by: Naveen Neelakantam, Francesco
// Spadini, and Wojciech Stryjewski.
//
//===----------------------------------------------------------------------===//
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/Analysis/Passes.h"
#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"
[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/Module.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"
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> PrintMod("print-mod", cl::ReallyHidden);
static cl::opt<bool> PrintRef("print-ref", cl::ReallyHidden);
static cl::opt<bool> PrintModRef("print-modref", 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
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
namespace {
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
class AAEval : public FunctionPass {
[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
unsigned NoAliasCount, MayAliasCount, PartialAliasCount, MustAliasCount;
unsigned NoModRefCount, ModCount, RefCount, ModRefCount;
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
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
public:
static char ID; // Pass identification, replacement for typeid
Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize the pass's dependencies. Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h before parsing commandline arguments. I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass registration/creation, please send the testcase to me directly. llvm-svn: 116820
2010-10-20 01:21:58 +08:00
AAEval() : FunctionPass(ID) {
initializeAAEvalPass(*PassRegistry::getPassRegistry());
}
Do not use typeinfo to identify pass in pass manager. llvm-svn: 36632
2007-05-02 05:15:47 +08:00
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 202945
2014-03-05 15:30:04 +08:00
void getAnalysisUsage(AnalysisUsage &AU) const override {
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
2015-09-10 01:55:00 +08:00
AU.addRequired<AAResultsWrapperPass>();
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
AU.setPreservesAll();
}
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 202945
2014-03-05 15:30:04 +08:00
bool doInitialization(Module &M) override {
[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 = 0;
NoModRefCount = ModCount = RefCount = ModRefCount = 0;
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
if (PrintAll) {
Teach AliasAnalysisEvaluator about PartialAlias. llvm-svn: 121512
2010-12-11 03:52:40 +08:00
PrintNoAlias = PrintMayAlias = true;
PrintPartialAlias = PrintMustAlias = true;
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
PrintNoModRef = PrintMod = PrintRef = PrintModRef = true;
}
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
return false;
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
}
[C++11] Add 'override' keyword to virtual methods that override their base class. llvm-svn: 202945
2014-03-05 15:30:04 +08:00
bool runOnFunction(Function &F) override;
bool doFinalization(Module &M) override;
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
};
Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC) Apparently, the style needs to be agreed upon first. llvm-svn: 240390
2015-06-23 17:49:53 +08:00
}
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
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
char AAEval::ID = 0;
Begin adding static dependence information to passes, which will allow us to perform initialization without static constructors AND without explicit initialization by the client. For the moment, passes are required to initialize both their (potential) dependencies and any passes they preserve. I hope to be able to relax the latter requirement in the future. llvm-svn: 116334
2010-10-13 03:48:12 +08:00
INITIALIZE_PASS_BEGIN(AAEval, "aa-eval",
"Exhaustive Alias Analysis Precision Evaluator", false, true)
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
2015-09-10 01:55:00 +08:00
INITIALIZE_PASS_DEPENDENCY(AAResultsWrapperPass)
Begin adding static dependence information to passes, which will allow us to perform initialization without static constructors AND without explicit initialization by the client. For the moment, passes are required to initialize both their (potential) dependencies and any passes they preserve. I hope to be able to relax the latter requirement in the future. llvm-svn: 116334
2010-10-13 03:48:12 +08:00
INITIALIZE_PASS_END(AAEval, "aa-eval",
Now with fewer extraneous semicolons! llvm-svn: 115996
2010-10-08 06:25:06 +08:00
"Exhaustive Alias Analysis Precision Evaluator", false, true)
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
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
FunctionPass *llvm::createAAEvalPass() { return new AAEval(); }
Add even more missing createXxxPass functions. llvm-svn: 19402
2005-01-09 06:01:16 +08:00
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
static void PrintResults(const char *Msg, bool P, const Value *V1,
const Value *V2, const Module *M) {
Allow printing of various types of alias analysis results llvm-svn: 5520
2003-02-10 04:40:13 +08:00
if (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
}
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);
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << " " << Msg << ":\t"
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
<< o1 << ", "
<< o2 << "\n";
Allow printing of various types of alias analysis results llvm-svn: 5520
2003-02-10 04:40:13 +08:00
}
}
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
static inline void
Print modref information in a useful way. llvm-svn: 14907
2004-07-17 14:43:20 +08:00
PrintModRefResults(const char *Msg, bool P, Instruction *I, Value *Ptr,
Module *M) {
if (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
}
}
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
static inline void
PrintModRefResults(const char *Msg, bool P, CallSite CSA, CallSite CSB,
Module *M) {
if (P) {
errs() << " " << Msg << ": " << *CSA.getInstruction()
<< " <-> " << *CSB.getInstruction() << '\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
static inline void
PrintLoadStoreResults(const char *Msg, bool P, const Value *V1,
const Value *V2, const Module *M) {
if (P) {
errs() << " " << Msg << ": " << *V1
<< " <-> " << *V2 << '\n';
}
}
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);
}
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
bool AAEval::runOnFunction(Function &F) {
[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] Rebuild LLVM's alias analysis infrastructure in a way compatible with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
2015-09-10 01:55:00 +08:00
AliasAnalysis &AA = getAnalysis<AAResultsWrapperPass>().getAAResults();
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;
Default SetVector to use a DenseSet. We use to have an odd difference among MapVector and SetVector. The map used a DenseMop, but the set used a SmallSet, which in turn uses a std::set. I have changed SetVector to use a DenseSet. If you were depending on the old behaviour you can pass an explicit set type or use SmallSetVector. The common cases for needing to do it are: * Optimizing for small sets. * Sets for types not supported by DenseSet. llvm-svn: 253439
2015-11-18 14:52:18 +08:00
SmallSetVector<CallSite, 16> CallSites;
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
Count operands to instructions as well as just results. This allows for global variables to be checked as well llvm-svn: 6970
2003-06-29 08:07:11 +08:00
for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) {
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
if (I->getType()->isPointerTy()) // Add all pointer instructions.
Changes to fix up the inst_iterator to pass to boost iterator checks. This patch was graciously contributed by Vladimir Prus. llvm-svn: 13185
2004-04-27 23:13:33 +08:00
Pointers.insert(&*I);
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 && isa<LoadInst>(&*I))
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
Loads.insert(&*I);
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 && isa<StoreInst>(&*I))
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
Stores.insert(&*I);
Do not include the Function* for direct call/invoke instructions in the alias evaluation. Clients really don't care. llvm-svn: 20664
2005-03-18 04:25:04 +08:00
Instruction &Inst = *I;
[CallSite] Make construction from Value* (or Instruction*) explicit. CallSite roughly behaves as a common base CallInst and InvokeInst. Bring the behavior closer to that model by making upcasts explicit. Downcasts remain implicit and work as before. Following dyn_cast as a mental model checking whether a Value *V isa CallSite now looks like this: if (auto CS = CallSite(V)) // think dyn_cast instead of: if (CallSite CS = V) This is an extra token but I think it is slightly clearer. Making the ctor explicit has the advantage of not accidentally creating nullptr CallSites, e.g. when you pass a Value * to a function taking a CallSite argument. llvm-svn: 234601
2015-04-10 22:50:08 +08:00
if (auto CS = CallSite(&Inst)) {
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
Value *Callee = CS.getCalledValue();
// Skip actual functions for direct function calls.
if (!isa<Function>(Callee) && isInterestingPointer(Callee))
Pointers.insert(Callee);
// Consider formals.
[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
for (Use &DataOp : CS.data_ops())
if (isInterestingPointer(DataOp))
Pointers.insert(DataOp);
simplify llvm-svn: 109585
2010-07-28 23:31:37 +08:00
CallSites.insert(CS);
clean up algorithm and remove operand order assumptions llvm-svn: 100780
2010-04-09 00:46:24 +08:00
} else {
// Consider all operands.
for (Instruction::op_iterator OI = Inst.op_begin(), OE = Inst.op_end();
OI != OE; ++OI)
if (isInterestingPointer(*OI))
Pointers.insert(*OI);
}
Evaluate ModRef information in addition to regular ol' pointer analysis. llvm-svn: 12331
2004-03-12 14:15:08 +08:00
}
Teach AliasAnalysisEvaluator about PartialAlias. llvm-svn: 121512
2010-12-11 03:52:40 +08:00
if (PrintNoAlias || PrintMayAlias || PrintPartialAlias || PrintMustAlias ||
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
PrintNoModRef || PrintMod || PrintRef || PrintModRef)
errs() << "Function: " << F.getName() << ": " << Pointers.size()
<< " pointers, " << CallSites.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) {
[PM/AA] Remove the UnknownSize static member from AliasAnalysis. This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
2015-06-17 15:21:38 +08:00
uint64_t I1Size = MemoryLocation::UnknownSize;
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();
[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
if (I1ElTy->isSized()) I1Size = 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) {
[PM/AA] Remove the UnknownSize static member from AliasAnalysis. This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
2015-06-17 15:21:38 +08:00
uint64_t I2Size = MemoryLocation::UnknownSize;
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 *I2ElTy =cast<PointerType>((*I2)->getType())->getElementType();
[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
if (I2ElTy->isSized()) I2Size = DL.getTypeStoreSize(I2ElTy);
When evaluating an AA, pass in size info llvm-svn: 18264
2004-11-27 05:05:39 +08:00
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
switch (AA.alias(*I1, I1Size, *I2, I2Size)) {
[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:
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
PrintResults("NoAlias", 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:
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
PrintResults("MayAlias", 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:
Teach AliasAnalysisEvaluator about PartialAlias. llvm-svn: 121512
2010-12-11 03:52:40 +08:00
PrintResults("PartialAlias", 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:
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
PrintResults("MustAlias", 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
for (SetVector<Value *>::iterator I1 = Loads.begin(), E = Loads.end();
I1 != E; ++I1) {
for (SetVector<Value *>::iterator I2 = Stores.begin(), E2 = Stores.end();
I2 != E2; ++I2) {
[PM/AA] Start refactoring AliasAnalysis to remove the analysis group and port it to the new pass manager. All this does is extract the inner "location" class used by AA into its own full fledged type. This seems *much* cleaner as MemoryDependence and soon MemorySSA also use this heavily, and it doesn't make much sense being inside the AA infrastructure. This will also make it much easier to break apart the AA infrastructure into something that stands on its own rather than using the analysis group design. There are a few places where this makes APIs not make sense -- they were taking an AliasAnalysis pointer just to build locations. I'll try to clean those up in follow-up commits. Differential Revision: http://reviews.llvm.org/D10228 llvm-svn: 239003
2015-06-04 10:03:15 +08:00
switch (AA.alias(MemoryLocation::get(cast<LoadInst>(*I1)),
MemoryLocation::get(cast<StoreInst>(*I2)))) {
[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:
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
PrintLoadStoreResults("NoAlias", 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:
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
PrintLoadStoreResults("MayAlias", 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:
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
PrintLoadStoreResults("PartialAlias", 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:
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
PrintLoadStoreResults("MustAlias", 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
}
}
}
// 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) {
[PM/AA] Start refactoring AliasAnalysis to remove the analysis group and port it to the new pass manager. All this does is extract the inner "location" class used by AA into its own full fledged type. This seems *much* cleaner as MemoryDependence and soon MemorySSA also use this heavily, and it doesn't make much sense being inside the AA infrastructure. This will also make it much easier to break apart the AA infrastructure into something that stands on its own rather than using the analysis group design. There are a few places where this makes APIs not make sense -- they were taking an AliasAnalysis pointer just to build locations. I'll try to clean those up in follow-up commits. Differential Revision: http://reviews.llvm.org/D10228 llvm-svn: 239003
2015-06-04 10:03:15 +08:00
switch (AA.alias(MemoryLocation::get(cast<StoreInst>(*I1)),
MemoryLocation::get(cast<StoreInst>(*I2)))) {
[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:
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
PrintLoadStoreResults("NoAlias", 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:
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
PrintLoadStoreResults("MayAlias", 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:
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
PrintLoadStoreResults("PartialAlias", 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:
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
PrintLoadStoreResults("MustAlias", 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
Default SetVector to use a DenseSet. We use to have an odd difference among MapVector and SetVector. The map used a DenseMop, but the set used a SmallSet, which in turn uses a std::set. I have changed SetVector to use a DenseSet. If you were depending on the old behaviour you can pass an explicit set type or use SmallSetVector. The common cases for needing to do it are: * Optimizing for small sets. * Sets for types not supported by DenseSet. llvm-svn: 253439
2015-11-18 14:52:18 +08:00
for (auto C = CallSites.begin(), Ce = CallSites.end(); C != Ce; ++C) {
Interchange this loop so that we test all pointers against one call site before moving on to the next call site. This will be a more efficient way to compute the mod/ref set for AA implementations like DSA. llvm-svn: 20866
2005-03-27 06:16:44 +08:00
Instruction *I = C->getInstruction();
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +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 V = Pointers.begin(), Ve = Pointers.end();
Interchange this loop so that we test all pointers against one call site before moving on to the next call site. This will be a more efficient way to compute the mod/ref set for AA implementations like DSA. llvm-svn: 20866
2005-03-27 06:16:44 +08:00
V != Ve; ++V) {
[PM/AA] Remove the UnknownSize static member from AliasAnalysis. This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
2015-06-17 15:21:38 +08:00
uint64_t Size = MemoryLocation::UnknownSize;
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 *ElTy = cast<PointerType>((*V)->getType())->getElementType();
[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
if (ElTy->isSized()) Size = DL.getTypeStoreSize(ElTy);
Remove trailing whitespace llvm-svn: 21416
2005-04-22 05:13:18 +08:00
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
switch (AA.getModRefInfo(*C, *V, Size)) {
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_NoModRef:
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
PrintModRefResults("NoModRef", PrintNoModRef, I, *V, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_Mod:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Just Mod", PrintMod, I, *V, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_Ref:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Just Ref", PrintRef, I, *V, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_ModRef:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Both ModRef", PrintModRef, I, *V, 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;
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
Default SetVector to use a DenseSet. We use to have an odd difference among MapVector and SetVector. The map used a DenseMop, but the set used a SmallSet, which in turn uses a std::set. I have changed SetVector to use a DenseSet. If you were depending on the old behaviour you can pass an explicit set type or use SmallSetVector. The common cases for needing to do it are: * Optimizing for small sets. * Sets for types not supported by DenseSet. llvm-svn: 253439
2015-11-18 14:52:18 +08:00
for (auto C = CallSites.begin(), Ce = CallSites.end(); C != Ce; ++C) {
for (auto D = CallSites.begin(); D != Ce; ++D) {
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
if (D == C)
continue;
switch (AA.getModRefInfo(*C, *D)) {
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_NoModRef:
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
PrintModRefResults("NoModRef", PrintNoModRef, *C, *D, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_Mod:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Just Mod", PrintMod, *C, *D, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_Ref:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Just Ref", PrintRef, *C, *D, 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;
[PM/AA] Extract the ModRef enums from the AliasAnalysis class in preparation for de-coupling the AA implementations. In order to do this, they had to become fake-scoped using the traditional LLVM pattern of a leading initialism. These can't be actual scoped enumerations because they're bitfields and thus inherently we use them as integers. I've also renamed the behavior enums that are specific to reasoning about the mod/ref behavior of functions when called. This makes it more clear that they have a very narrow domain of applicability. I think there is a significantly cleaner API for all of this, but I don't want to try to do really substantive changes for now, I just want to refactor the things away from analysis groups so I'm preserving the exact original design and just cleaning up the names, style, and lifting out of the class. Differential Revision: http://reviews.llvm.org/D10564 llvm-svn: 242963
2015-07-23 07:15:57 +08:00
case MRI_ModRef:
The trouble with testing for "ModRef" and "NoModRef" is that one is a suffix of the other, and FileCheck accepts superstrings. Adjust the output to avoid this problem. llvm-svn: 110280
2010-08-05 07:37:55 +08:00
PrintModRefResults("Both ModRef", PrintModRef, *C, *D, 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;
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
}
}
}
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
return false;
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
}
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
static void PrintPercent(unsigned Num, unsigned Sum) {
Change dbgs() back to errs() as Chris requested. llvm-svn: 92073
2009-12-24 06:49:57 +08:00
errs() << "(" << Num*100ULL/Sum << "."
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
<< ((Num*1000ULL/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
}
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
bool AAEval::doFinalization(Module &M) {
[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
unsigned AliasSum =
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
[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
unsigned ModRefSum = NoModRefCount + ModCount + RefCount + ModRefCount;
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);
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
<< "%/" << ModRefCount * 100 / ModRefSum << "%\n";
Fix division by zero problem llvm-svn: 5509
2003-02-09 07:04:50 +08:00
}
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
return false;
Simple N^2 alias anlysis accuracy checker llvm-svn: 5498
2003-02-07 05:29:49 +08:00
}