search for: terminatorinst

...piling my pass. I was moving my development environment and updated LLVM to the trunk number 350084 in the meantime. [ 11%] Building CXX object lib/Transforms/TimePred/CMakeFiles/TimePred.dir/Common/Formatter.cpp.o /home/gwangmu/opt/llvm/lib/Transforms/TimePred/Common/Formatter.cpp:182:24: error: ‘TerminatorInst’ was not declared in this scope void Formatter::write<TerminatorInst *>(TerminatorInst *obj) ^~~~~~~~~~~~~~ /home/gwangmu/opt/llvm/lib/Transforms/TimePred/Common/Formatter.cpp:182:18: error: parse error in template argument list void Formatter::write<TerminatorI...

Under what circumstances will a TerminatorInst will have multiple successors? The three methods: virtual BasicBlock *getSuccessorV(unsigned idx) const = 0; virtual unsigned getNumSuccessorsV() const = 0; virtual void setSuccessorV(unsigned idx, BasicBlock *B) = 0; are defined for the TerminatorInst class, but I cannot see why a termina...

...$_ZN4llvm10BranchInstC1EPNS_10BasicBlockES2_+0x52): In function `ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPN4llvm8FunctionEPNS3_5GraphEEEE10deallocateEPSA_j': c:/MinGW/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/ext/new_allocator.h: undefined reference to `llvm::TerminatorInst::TerminatorInst(llvm::Instruction::TermOps, llvm::BasicBlock*)' c:/projects/build/MinGW/llvm-4-1/Debug/lib/LLVMProfilePaths.o(.text$_ZN4llvm10BranchInstC1EPNS_10BasicBlockES2_+0x74):c:/MinGW/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/ext/new_allocator.h: undefined reference to...

Hi Jeff, > Under what circumstances will a TerminatorInst will have multiple successors? for example when it is a condition branch (two successors), an invoke (also two successors) or a switch (maybe many successors). Ciao, Duncan.

+1, sounds like a great idea And if you're volunteering to do the work, even better! :) Philip p.s. Any reason we can't preserve a TerminatorInst type with an isa function which just returns true for all our terminators but without having terminators actually inherit from it?  If so, we preserve the bit of a "type safety" for a variable which is expected to always point to a terminator. On 05/17/2018 02:03 AM, Chandler Carrut...

...he ResolvedUndefsIn in 2.7? We've hit this particular stack a couple times now in the JIT. I've copied the failing bitcode to disk and doesn't crash opt or llc. It doesn't repro easily in the JIT either, but the stack is always the same... hoping it's a known issue. Thanks! TerminatorInst *TI = BB->getTerminator(); >>>>if (BranchInst *BI = dyn_cast<BranchInst>(TI)) { if (!BI->isConditional()) continue; #0 llvm::Value::getValueID (this=0xfffffd7fecbef3c0, F=<value optimized out>) at ./llvm-2.7/include/llvm/Value.h:247 #1 llvm::Instruction::getOp...

> On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to specific instructions to be implemented. > > On the flip side, CallInst and InvokeInst ha...

...lock? I.e., how would one find the terminating instruction in that case? By iterating over all of them or ...? Cheers, Alex. > On 17. May 2018, at 11:03, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to specific instructions to be implemented. > > On the flip side, CallInst and InvokeInst ha...

On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches to > specific instructions to be implemented. > > On the flip side, CallInst and...

...rminators now, but will become terminators with this change? I'm wondering if this is going to affect reading old bitcode, and if so, how it will be handled. -Krzysztof On 5/17/2018 4:03 AM, Chandler Carruth via llvm-dev wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches > to specific instructions to be implemented. > > On the flip side, CallInst...

Hi, Is changing the successors for each basic blocks means by default that the Terminator Instruction will be changed or this is another problem should be solved? If case 2 please tell me how to change it according to the new successors? Thanks -- * Rasha Salah Omar Msc Student at E-JUST Demonestrator at Faculty of Computers and Informatics Benha University* * e-mail:

Hi Rasha, > Is changing the successors for each basic blocks means by default that the > Terminator Instruction will be changed or this is another problem should be > solved? I think the only way you *can* change a basic block's successors is by changing its terminator instruction, so "by default" is the closest answer. Though you should make sure your basic block only has

...18 at 10:26 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Going to keep this RFC short and to the point: > > > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches to > specific instructions to be implemented. > > > > On the flip side, Ca...

On 05/17/2018 04:03 AM, Chandler Carruth via llvm-dev wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just > dispatches to specific instructions to be implemented. > > On the flip side, CallInst and...

...iang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Going to keep this RFC short and to the point: >>> >>> TerminatorInst doesn't pull its weight in the type system. There is >>> essentially a single relevant API -- iterating successors. There is no >>> other interesting aspect shared -- the interface itself just dispatches to >>> specific instructions to be implemented. >>> &gt...

On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Going to keep this RFC short and to the point: >> >> TerminatorInst doesn't pull its weight in the type system. There is >> essentially a single relevant API -- iterating successors. There is no >> other interesting aspect shared -- the interface itself just dispatches to >> specific instructions to be implemented. >> >> On the fli...

Hi, The checking about that if this is a terminator that it is at the end of the block has been applied twice (bellow). One is at Verifier::visitInstruction, and the other is at Verifier::visitTerminatorInst. Since visitInstruction is called when visiting each instruction, the checking at visitTerminatorInst seems redundant to me. Did I miss any case? void Verifier::visitInstruction(Instruction &I) { ... line 1356: // Verify that if this is a terminator that it is at the end of the block. if (...

Going to keep this RFC short and to the point: TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to specific instructions to be implemented. On the flip side, CallInst and InvokeInst have *massiv...

Hi All, I need to remove successors from every basic block to insert new ones I tried this code, but it doesn't work void RemoveSuccessor(TerminatorInst *TI, unsigned SuccNum) { assert(SuccNum < TI->getNumSuccessors() && "Trying to remove a nonexistant successor!"); // If our old successor block contains any PHI nodes, remove the entry in the // PHI nodes that comes from this branch... // BasicBlo...

...isn't safe to hoist something > that reads >      // memory (without proving that the loop doesn't write). >      if (L->hasLoopInvariantOperands(Inst) && >          !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && >          !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { >        Inst->moveBefore(LoopEntryBranch); >        continue; >      } > > The above code happily moves an alloca instruction out of the loop, to > the new loop header. Shouldn't we also check on > >   !isa&l...