search for: deletevalu

Greetings folks, As I'm working on refactoring the AA interfaces in LLVM to prepare for the new pass manager, I keep hitting issues. Some of the complexity that is hitting this stems from the update API, which consists of three virtual functions: deleteValue(Value *V) copyValue(Value *From, Value *To) addEscapingUse(Use &U) These interfaces are *very* rarely called. Here are the only passes that ever bother to use these: - MemoryDependenceAnalysis.cpp - BasicBlockUtils.cpp - LoopSimplify.cpp - MergedLoadStoreMotion.cpp - GVN.cpp That's it. T...

...*__GI___assert_fail (assertion=0xf78ef62c "AA && \"AA didn't call InitializeAliasAnalysis in its run method!\"", file=0xf78ef5f0 "/x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp", line=59, function=0xf78f0e40 "virtual void llvm::AliasAnalysis::deleteValue(llvm::Value*)") at assert.c:81 #4 0xf6c37686 in llvm::AliasAnalysis::deleteValue (this=0x81848d0, V=0x8147000) at /x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp:59 #5 0xf6c47153 in llvm::AliasSetTracker::deleteValue (this=0x823ab58, PtrVal=0x8147000) at /x/grwright/llvm/llvm-...

...gt; As I'm working on refactoring the AA interfaces in LLVM to prepare > > for the new pass manager, I keep hitting issues. Some of the > > complexity that is hitting this stems from the update API, which > > consists of three virtual functions: > > > > > > deleteValue(Value *V) > > copyValue(Value *From, Value *To) > > addEscapingUse(Use &U) > > > > > > These interfaces are *very* rarely called. Here are the only passes > > that ever bother to use these: > > - MemoryDependenceAnalysis.cpp > > - BasicBlockUti...

...ef62c "AA&& \"AA didn't call >> InitializeAliasAnalysis in its run method!\"", file=0xf78ef5f0 >> "/x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp", line=59, >> function=0xf78f0e40 "virtual void >> llvm::AliasAnalysis::deleteValue(llvm::Value*)") at assert.c:81 #4 >> 0xf6c37686 in llvm::AliasAnalysis::deleteValue (this=0x81848d0, >> V=0x8147000) at >> >> /x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp:59 >> >> #5 0xf6c47153 in llvm::AliasSetTracker::deleteValue (this=0x...

...(assertion=0xf78ef62c "AA&& \"AA didn't call > InitializeAliasAnalysis in its run method!\"", file=0xf78ef5f0 > "/x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp", line=59, > function=0xf78f0e40 "virtual void > llvm::AliasAnalysis::deleteValue(llvm::Value*)") at assert.c:81 #4 > 0xf6c37686 in llvm::AliasAnalysis::deleteValue (this=0x81848d0, > V=0x8147000) at > > /x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp:59 > > #5 0xf6c47153 in llvm::AliasSetTracker::deleteValue (this=0x823ab58, > PtrVal=0x8...

...___assert_fail (assertion=0xf78ef62c "AA && \"AA didn't call InitializeAliasAnalysis in its run method!\"", file=0xf78ef5f0 "/x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp", line=59, function=0xf78f0e40 "virtual void llvm::AliasAnalysis::deleteValue(llvm::Value*)") at assert.c:81 #4 0xf6c37686 in llvm::AliasAnalysis::deleteValue (this=0x81848d0, V=0x8147000) at /x/grwright/llvm/llvm-2.9/lib/Analysis/AliasAnalysis.cpp:59 #5 0xf6c47153 in llvm::AliasSetTracker::deleteValue (this=0x823ab58, PtrVal=0x8147000) at /x/grwright/llvm/llvm-2.9/l...

On Saturday 04 October 2008 17:05, Chris Lattner wrote: > Looking more closely at the approach, I infer that the (logical in > hindsight) issue are cases where mem2reg scans a BB to see the > relative ordering of two instructions. For example, the single store Correct. > case. I could imagine that if you saw lots of single store allocas in > the middle of a large BB that

...= UseBlock->end(); I != E; ) { if (LoadInst *LI = dyn_cast<LoadInst>(I++)) { if (LI->getOperand(0) == AI) { LI->replaceAllUsesWith(OnlyStore->getOperand(0)); if (AST && isa<PointerType>(LI->getType())) AST->deleteValue(LI); LI->eraseFromParent(); } } } I suppose we could resctrict the map to containing only load and store instructions but if you've got a block with a lot of memory instructions I'm not sure it will be much faster, especially with the second loop. The art...

Hello, In an effort to help LLVM-style projects save memory, I’ve been toying with some macros that provide an alternative to C++ vtables that use LLVM-style RTTI design patterns instead. Is this something that LLVM or sub-projects think is worth pursuing? Or are the macros below too ugly/problematic? Feedback would be appreciated. Thanks, Dave //===- llvm/Support/VTable.h - LLVM-style

On Oct 4, 2008, at 2:51 PM, Chris Lattner wrote: >>> I like your approach of using the use lists but I'm not sure the >>> ordering >>> is guaranteed. If it is, your approach is superior. >> >> I got my patch updated to work with TOT. Here it is. Comments >> welcome. > > Hi Dave, > > Great. I'd like to get this in, but would

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >