search for: institerator

...or which either: - point to instructions in the same basic block (the first one first, second one second) - point to instructions in different basic block (the BB of the first dominate the BB of the second, and the BB of the second post-dominate the BB of the first) I'm not sure if I can trick InstIterator into doing that for me (with a custom BB type?). -- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/375a02b6/attachment.html>

...; - point to instructions in the same basic block (the first one first, second one second) > - point to instructions in different basic block (the BB of the first dominate the BB of the second, and the BB of the second post-dominate the BB of the first) > > I'm not sure if I can trick InstIterator into doing that for me (with a custom BB type?). > > -- > Alexandre Isoard > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------...

...s > > as if value_type is Instruction. Hmm ;-) > > Yeah, fishy huh? :) Yea, a bit. I've decided that before changing that I'd better find other problems, if any, so I run inst_iterator via checks provided by Boost.Iterators. First problem is that inst_iterator (and actually InstIterator class template) is not Assignable, because it has a reference data member, while standard requires all iterators to be assignable. Second InstIterator is not DefaultConstructile, which is required from Forwarditerator. Also, I get error because InstIterator::difference_type is not signed integ...

...> + // operating on the same trampoline). Of course, this is useless if there are > + // writes to the trampoline between the two instructions. > + > + // We look at all the instructions before the adjust.trampoline in its basic > + // block. > + > + BasicBlock::iterator InstIterator = AdjustTramp, > + InstBegin = AdjustTramp->getParent()->begin(); > + IntrinsicInst *In = NULL; Why is In defined here and not locally inside the loop below? > + > + InstIterator--; What if AdjustTramp was the first instruction in the basic block? I think you should first...

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

On Fri, 23 Apr 2004, Vladimir Prus wrote: > Yea, I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator->

...2004, Vladimir Prus wrote: > > Yeah, fishy huh? :) > > Yea, a bit. I've decided that before changing that I'd better find other > problems, if any, so I run inst_iterator via checks provided by > Boost.Iterators. > > First problem is that inst_iterator (and actually InstIterator class template) > is not Assignable, because it has a reference data member, while standard > requires all iterators to be assignable. Ok. > Second InstIterator is not DefaultConstructile, which is required from > Forwarditerator. Ok, makes sense. > Also, I get error because Inst...

Chris Lattner wrote: > On Fri, 23 Apr 2004, Vladimir Prus wrote: > > and since result of *it is considered to be rvalue it can't be accepted > > by this operator. The complete discussion is in > > > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm > > > > I'd suggest to apply the following patch which makes operator* return >

...include "llvm/Analysis/LoopInfo.h" #include "llvm/ADT/SmallBitVector.h" and a .cpp file including only #include "myHeader.h" #include "llvm/Analysis/ScalarEvolutionExpressions.h" #include "llvm/Analysis/ValueTracking.h" #include "llvm/Support/InstIterator.h" Is it good style to cut the list down to the bare minimum like this? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120611/090ed848/attachment.html>

...tructureForTrace.push_back (std:make_tuple(new Value(threadId), AddrSpace, 0, new Value(AddrPointer))); } } I get following error (there are more, some visible here and some not. for eg, getAddressSpace not being for Instruction class.): error: cannot convert ‘llvm::inst_iterator {aka llvm::InstIterator<llvm::SymbolTableList<llvm::BasicBlock>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::BasicBlock, false, false, void>, false, false>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, false>, llvm::In...

...d:make_tuple(new Value(threadId), AddrSpace, 0, new Value(AddrPointer))); > } > } > > I get following error (there are more, some visible here and some not. for eg, getAddressSpace not being for Instruction class.): > > error: cannot convert ‘llvm::inst_iterator {aka llvm::InstIterator<llvm::SymbolTableList<llvm::BasicBlock>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::BasicBlock, false, false, void>, false, false>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, false>, llvm::In...

...-------------------- * Modifying bitcode inliner.cpp ----------------------------------------------------------------- #include "llvm/IR/Type.h" #include "llvm/IR/Module.h" #include "llvm/IR/Function.h" #include "llvm/IR/GlobalValue.h" #include "llvm/IR/InstIterator.h" #include "llvm/IR/Instructions.h" #include "llvm/IR/IRBuilder.h" #include "llvm/Support/SourceMgr.h" #include "llvm/IRReader/IRReader.h" #include "llvm/Support/FileSystem.h" #include "llvm/Bitcode/ReaderWriter.h" #include "llv...

...itcode > inliner.cpp > ----------------------------------------------------------------- > #include "llvm/IR/Type.h" > #include "llvm/IR/Module.h" > #include "llvm/IR/Function.h" > #include "llvm/IR/GlobalValue.h" > #include "llvm/IR/InstIterator.h" > #include "llvm/IR/Instructions.h" > #include "llvm/IR/IRBuilder.h" > #include "llvm/Support/SourceMgr.h" > #include "llvm/IRReader/IRReader.h" > #include "llvm/Support/FileSystem.h" > #include "llvm/Bitcode/ReaderWri...

...>> ----------------------------------------------------------------- >> #include "llvm/IR/Type.h" >> #include "llvm/IR/Module.h" >> #include "llvm/IR/Function.h" >> #include "llvm/IR/GlobalValue.h" >> #include "llvm/IR/InstIterator.h" >> #include "llvm/IR/Instructions.h" >> #include "llvm/IR/IRBuilder.h" >> #include "llvm/Support/SourceMgr.h" >> #include "llvm/IRReader/IRReader.h" >> #include "llvm/Support/FileSystem.h" >> #include &quo...

...pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h (which was required to use inst_iterator in the *template <> struct GraphTraits<DFG<Function*> >*) to MachineInstrIterator.h to iterate over machine instructions in a machine function. But the build is throwing the following error: llvm[2]: Compiling MC_DFG.cpp for Debug+Assert...

...LVM IR functions. This > was based on the mail thread - > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. > This pass worked fine and I was able to generate DFG of LLVM IR functions. > > Later, I ported the DFG pass code for machine functions. I ported the > InstIterator.h (which was required to use inst_iterator in the *template > <> struct GraphTraits<DFG<Function*> >*) to MachineInstrIterator.h to > iterate over machine instructions in a machine function. But the build is > throwing the following error: > > llvm[2]: Compiling MC_...

...lativePath="..\..\include\llvm\Support\GetElementPtrTypeIterator.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\GraphWriter.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\InstIterator.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\InstVisitor.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\LeakDetector.h"> > + </File> > + <File &gt...

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

...ude "llvm/Module.h" #include "llvm/Function.h" #include "llvm/Constants.h" #include "llvm/Instructions.h" #include "llvm/Support/CFG.h" #include "llvm/Support/Debug.h" #include "llvm/Support/Casting.h" #include "llvm/Support/InstIterator.h" #include "MakeDispatcherPass.h" // // Static variables. // const std::string MakeDispatcherPass::PassName = "MakeDispatcherPass"; // // Public methods. // bool MakeDispatcherPass::runOnFunction( Function& currFunction ) { DEBUG( std::cerr << PassName &...

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the