search for: blockt

...d to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build MachineLoopInfo.cpp: In instantiation of `llvm::LoopBase<BlockT>::LoopBase(const llvm::LoopBase<BlockT>&) [with BlockT = llvm::MachineBasicBlock]': MachineLoopInfo.cpp:22: instantiated from here MachineLoopInfo.cpp:22: error: explicit instantiation of `llvm::LoopBase<BlockT>::LoopBase(const llvm::LoopBase<BlockT>&) [with Block...

Hi, I was reading some loop related code and I don’t quite understand an assertion in LoopBase<BlockT, LoopT>::getLoopPredecessor(). /// getLoopPredecessor - If the given loop's header has exactly one unique /// predecessor outside the loop, return it. Otherwise return null. /// This is less strict that the loop "preheader" concept, which requires /// the predecessor to have exact...

SVN head LLVM and Clang built out of the box for me a week ago on MSYS/ MINGW, using the following files: MinGW-5.1.3.exe MSYS-1.0.10.exe msysDTK-1.0.1.exe bash-3.1-MSYS-1.0.11-1.tar.bz2 bison-2.3-MSYS-1.0.11.tar.bz2 coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 flex-2.5.33-MSYS-1.0.11.tar.bz2 gawk-3.1.5-MSYS-1.0.11-snapshot.tar.bz2 regex-0.12-MSYS-1.0.11.tar.bz2 1. install these components 2.

Hello, I'm trying to use LLVM on Windows, using the MinGW toolchain that comes with Cygwin (gcc -mno-cygwin, not the standalone msys package). Has anyone successfully built LLVM from sources with this toolchain? The ./configure scripts automatically detects a Cygwin environment. I've spent some time trying to let it know that it should compile for MinGW. FWIW, here's what I've

Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain situations. Should repetitive basic blocks be removed? I have an example to show the problem. Following is the source code and the CFG is enclosed...

...> +public: > + bool isRetired; > + int sccNum; > + //SmallVector<InstrT*, DEFAULT_VEC_SLOTS> succInstr; > + //Instructions defining the corresponding successor. > + BlockInformation() : isRetired(false), sccNum(INVALIDSCCNUM) {} > +}; > + > +template <class BlockT, class InstrT, class RegiT> > +class LandInformation { > +public: > + BlockT *landBlk; > + std::set<RegiT> breakInitRegs; //Registers that need to "reg = 0", before > + //WHILELOOP(thisloop) init before entering > +...

...replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void llvm::LoopBase<N, M>::verifyLoop() const [with BlockT = llvm::BasicBlock, LoopT = llvm::Loop]: Assertion `HasInsideLoopPreds && "Loop block has no in-loop predecessors!"' failed. Does this mean I should keep it still a loop after my pass? If so, how could I bypass it? -- *Thank you && Best Regards,* *Zhiyuan Yang* ---...

On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all > exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain > situations. Should repetitive basic blocks be removed? Users generally expect a unique set of exit blocks, but don't make any stro...

...a direction vector. IMHO it would be more clear in general, not only in the context of my project. Off course, it's only a cosmetic proposition and I'm not going to insist on that change. Currently, there are 2 methods to determine the depth of something: a) unsigned LoopInfo::getLoopDepth(BlockT *BB); // Return the loop nesting level of the specified block. b) unsigned Loop::getLoopDepth() // Return the nesting level of this loop. The reason why numbering in b) starts from 1 is to be consistent with numbering in a) (which starts from 0) --- the depth of BB is the same as the depth o...

...od. I will try to split it up myself first and ask when there are decisions to be made I'm not sure about. Ok! >>> +  /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). >>> +  /// (Modelled after getExitingBlocks().) >>> +  typedef std::pair<BlockT*,BlockT*> Edge; >>> +  void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { >>> +    // Sort the blocks vector so that we can use binary search to do quick >>> +    // lookups. >>> +    SmallVector<BlockT*, 128> LoopBBs(block_begin(), bl...

...he terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: > > opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void llvm::LoopBase<N, M>::verifyLoop() const [with BlockT = llvm::BasicBlock, LoopT = llvm::Loop]: Assertion `HasInsideLoopPreds && "Loop block has no in-loop predecessors!"' failed. > > Does this mean I should keep it still a loop after my pass? If so, how could I bypass it? You might need to call LPPassManager::deleteLoopFr...

...of latch with another BranchInst, and > the loop will not be a loop after my pass. However, it turns out a failure > of loopverify after executing my pass: > > opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void > llvm::LoopBase<N, M>::verifyLoop() const [with BlockT = llvm::BasicBlock, > LoopT = llvm::Loop]: Assertion `HasInsideLoopPreds && "Loop block has no > in-loop predecessors!"' failed. > > Does this mean I should keep it still a loop after my pass? If so, how > could I bypass it? > > > You might need to call...

...9; when possible. Finally, I have some other technical comments inline with the diff below. Thanks again for sharing your work! - Daniel > + /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). > + /// (Modelled after getExitingBlocks().) > + typedef std::pair<BlockT*,BlockT*> Edge; > + void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { > + // Sort the blocks vector so that we can use binary search to do quick > + // lookups. > + SmallVector<BlockT*, 128> LoopBBs(block_begin(), block_end()); > + std::sort(...

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

...yle: Well, they were to be expected :-) One never gets those right the first time contributing to a new project... > [...] >> + /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). >> + /// (Modelled after getExitingBlocks().) >> + typedef std::pair<BlockT*,BlockT*> Edge; >> + void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { >> + // Sort the blocks vector so that we can use binary search to do quick >> + // lookups. >> + SmallVector<BlockT*, 128> LoopBBs(block_begin(), block_end()); >...

Hy possible that it is a setting in the registry. See ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/ I'can't connect to the link (ftp is blockt at our site) but you houl'd see some information. if blockspace from your ehternetcard is less then 9.6 microseconds, you can run in problems. hope you'll find something cheers peter >>-----Urspr?ngliche Nachricht----- >>Von: Iap, Singuan [mailto:iap_yeh@thecus.com] >&gt...

I'm getting a lot of these from TOT make: /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In instantiation of 'llvm::LoopInfoBase<llvm::BasicBlock>': /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: instantiated from here /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: warning: 'class

...opy) @@ -580,9 +580,6 @@ LoopInfoBase() { } ~LoopInfoBase() { releaseMemory(); } - /// isAnalysis - Return true if this pass is implementing an analysis pass. - virtual bool isAnalysis() const { return true; } - void releaseMemory() { for (typename std::vector<LoopBase<BlockT>* >::iterator I = TopLevelLoops.begin(), E = TopLevelLoops.end(); I != E; ++I) @@ -922,6 +919,9 @@ return LI->isLoopHeader(BB); } + /// isAnalysis - Return true if this pass is implementing an analysis pass. + bool isAnalysis() const { return true; } + /// ru...

On Apr 23, 2012, at 10:31 PM, Andrew Trick <atrick at apple.com> wrote: > > On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > >> Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all >> exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain >> situations. Should repetitive basic blocks be removed? > > Users generally expect a unique set of exit blocks, but don...