search for: aaresults

Hi all, I am trying to use LLVM's AliasAnalysis pass, but from a standalone tool that uses llvm libraries. The following is the code snippet I am currently using. PassBuilder PB; auto mod_manager = ModuleAnalysisManager { }; PB.registerModuleAnalyses(mod_manager); AAResults& AAR = mod_manager.getResult<AAManager>(*M); But the code fails at .getResult with the following error: /llvm/include/llvm/IR/PassManager.h:778: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::AAMan...

On Apr 17, 2013, at 2:33 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 12:22:49 AM >> Subject: RE: [LLVMdev] alias analysis in backend

----- Original Message ----- > From: "Jonas Paulsson" <jonas.paulsson at ericsson.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 12:22:49 AM > Subject: RE: [LLVMdev] alias analysis in backend > > Hi Hal, > > Thanks. How about a symbol with two different immediate offsets - the

...Loop*, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, bool) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:830:3 llvm::LoopAccessInfo::analyzeLoop(llvm::AAResults*, llvm::LoopInfo*, llvm::TargetLibraryInfo const*, llvm::DominatorTree*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2038:8 llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::DominatorTree*, llvm::LoopInfo...

Hi Hal, Thanks. How about a symbol with two different immediate offsets - the Value* would be the same, right? I don't see how AliasAnalysis::Location would handle this... And BasicAliasAnalysis does if (V1 == V2) return MustAlias; , so I'm not sure how this would be done .. ? /Jonas > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent:

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jonas Paulsson" <jonas.paulsson at ericsson.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, April 18, 2013 2:33:52 AM > Subject: Re: [LLVMdev] alias analysis in backend > > > On Apr 17, 2013, at 2:33 AM,

...Loop*, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, bool) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:830:3 llvm::LoopAccessInfo::analyzeLoop(llvm::AAResults*, llvm::LoopInfo*, llvm::TargetLibraryInfo const*, llvm::DominatorTree*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2038:8 llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::DominatorTree*, llvm::LoopInfo...

On 03/28/2016 10:50 AM, Hal Finkel wrote: > > On 03/28/2016 12:37 AM, Chris Lattner wrote: > > It changes all the time. Here’s a trivial example, assume no > inlining and no AA other than the one in question: > > std::vector<int> V1 = { 1, 2, 3 }; > std::vector<int> V2 = { 4, 5, 6 }; > >

Hi, I'm writing an analysis pass which is supposed to find instructions in a function that modify function's by-ref arguments. For that I'm using llvm AliasAnalysis pass, particularly querying for ModRef info for instructions and function arguments, to see if a given instruction modifies a given argument. However, for functions with more than one by-ref argument, I get strange

...into two categories: 1) query-dependencies on "immutable" analysis results. These are results that we *never* expect to be invalidated and we just want easy access to. TargetLibraryInfo is the classic example here. 2) query-dependencies on normal analysis results. DominatorTree and and AAResults are the primary examples here. I would like to have a simple way to handle #1 by ensuring invalidation doesn't occur. I think this already works, but I'm interested if there is actually an issue here. We *could* handle #2 much like data-structure-dependencies, but I hear Hal and others th...

...66c 0x66c sink(llvm::Instruction&, llvm::LoopInfo*, llvm::DominatorTree*, llvm::Loop const*, llvm::ICFLoopSafetyInfo*, llvm::MemorySSAUpdater*, llvm::OptimizationRemarkEmitter*) #4 0x0000ffffad5f066c #5 0x0000ffffad5f066c llvm::sinkRegion(llvm::DomTreeNodeBase<llvm::BasicBlock>*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::TargetLibraryInfo*, llvm::TargetTransformInfo*, llvm::Loop*, llvm::AliasSetTracker*, llvm::MemorySSAUpdater*, llvm::ICFLoopSafetyInfo*, llvm::SinkAndHoistLICMFlags&, llvm::OptimizationRemarkEmitter*) (+0x66c) #6 0x00000000014228f8 (anonymous names...

this is definitely a bug in AA. 225 for (auto I = CS2.arg_begin(), E = CS2.arg_end(); I != E; ++I) { 226 const Value *Arg = *I; 227 if (!Arg->getType()->isPointerTy()) -> 228 continue; 229 unsigned CS2ArgIdx = std::distance(CS2.arg_begin(), I); 230 auto CS2ArgLoc = MemoryLocation::getForArgument(CS2, CS2ArgIdx, TLI);

...pl)' is freed much > earlier than 'Function Alias Analysis Results' even though the latter > depends on the former (at least AFAICT by looking > at lib/Analysis/AliasAnalysis.cpp)? > > > > As far as I can tell later passes such as scheduling typically depend on > AAResultsWrapperPass which in turn depend on BasicAAWrapperPass (which in > my case also depend on LazyValueInfoWrapperPass). When scheduling needs to > query aliasing it uses its AAResults handle but this may then use its > BasicAA handle which may use its LVI handle and now the problem is that &gt...

...) query-dependencies on "immutable" analysis results. These are results > that we *never* expect to be invalidated and we just want easy access to. > TargetLibraryInfo is the classic example here. > > 2) query-dependencies on normal analysis results. DominatorTree and and > AAResults are the primary examples here. > > I would like to have a simple way to handle #1 by ensuring invalidation > doesn't occur. I think this already works, but I'm interested if there is > actually an issue here. > > We *could* handle #2 much like data-structure-dependencies,...

...tachments/20160829/db3748fd/attachment.html> -------------- next part -------------- diff --git a/lib/Analysis/AliasAnalysis.cpp b/lib/Analysis/AliasAnalysis.cpp index f931b6f..ee51067 100644 --- a/lib/Analysis/AliasAnalysis.cpp +++ b/lib/Analysis/AliasAnalysis.cpp @@ -155,7 +155,7 @@ ModRefInfo AAResults::getModRefInfo(ImmutableCallSite CS, if (doesAccessArgPointees(MRB)) { for (auto AI = CS.arg_begin(), AE = CS.arg_end(); AI != AE; ++AI) { const Value *Arg = *AI; - if (!Arg->getType()->isPointerTy()) + if (!Arg->getType()->isPtrOrPtrVectorTy())...

...t; all. > > Do you have a sense of where these expensive domtree queries are > coming from? Are they from a couple of key places or are they > scattered throughout the pass pipeline? > When I dug into the profile with WPA, most of the time was spent in DSE and memcpyopt, which call AAResults::callCapturesBefore, which calls llvm::PointerMayBeCapturedBefore. Neither pass in an OrderedBasicBlock, so they rebuild the OrderedBasicBlock in linear time on every query. These passes insert instructions, so it's not correct to simply create and reuse an OrderedBasicBlock at this level. As...

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Hi, Elena, You're correct. We do assume that pointers in different address spaces can alias. Targets can add their own AA pass into the AA query chain, and one of the things such analysis passes can do account for target-specific knowledge of address-space semantics. For example, see lib/Target/AMDGPU/AMDGPUAliasAnalysis.cpp  -Hal On 04/26/2018 07:56 AM, Demikhovsky, Elena via llvm-dev

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

Hi, Looking at the output of e.g. llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll -debug-pass=Executions Why is it that 'Basic Alias Analysis (stateless AA impl)' is freed much earlier than 'Function Alias Analysis Results' even though the latter depends on the former (at least AFAICT by looking at lib/Analysis/AliasAnalysis.cpp)? Thanks! -Markus