similar to: [LLVMdev] Undefined references

I stumbled upon a baffling error while compiling 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

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 terminator is allowed to go to different targets. Thanks,

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

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 //

+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

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.

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is

I have been looking at some internal codes looking for differences between Clang (specifically 3.7.1) and gcc (typically 4.8.1 but sometimes later). One area where I bumped into was dead code elimination in the presence of complex control flow. I note that the “aggressive dead code elimination” (ADCE.cpp) treats all branch operations as live (isa<TerminatorInst>(I)). Doing more requires

> 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

Fernando Magno Quintao Pereira wrote: > I am in need of a no-op instruction: an instruction that does not do > anything, and has no operands. Does LLVM predefine such an instruction? I > want to transform the program so that there is no empty basic block. You can never have an empty basic block. All BBs must have a TerminatorInst. Nick

>> I am in need of a no-op instruction: an instruction that does not do >> anything, and has no operands. Does LLVM predefine such an instruction? I >> want to transform the program so that there is no empty basic block. > > You can never have an empty basic block. All BBs must have a TerminatorInst. > I've built a pass to split critical edges of machine

Hi I have checked all blocks, each block have a Terminator instruction and each blocks belongs to a function. I'm really confused. I guess the problem is caused by the removal of the Loop,The code is as follows: * //every block to header (except the ones in the loop), will now redirect to newblock for (pred_iterator PI = pred_begin(header); PI != pred_end(header); ++PI) {

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

Are there any instructions that aren't terminators 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

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

Hi, All I want to implement DSWP Which is used for parallelization of loops. For this purpose, the loop was replaced with a new basic block in main function. And new functions were created and basic blocks of Loop assigned to them.I have checked blocks and branches for Succ and Pred relation and I have not found any problems. However I get the following error: * **opt:

Is it possible to merge StructTypes with different names like: %"class.std::allocator.4" = type { i8 } %"class.__gnu_cxx::new_allocator.5" = type { i8 } %"class.std::allocator.0" = type { i8 } %"class.__gnu_cxx::new_allocator.1" = type { i8 } %"class.std::allocator.0.6" = type { i8 } merge into %"class.__gnu_cxx::new_allocator" = type

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 *massive* amounts of code shared and struggle

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.

Hi Михаил, > Is it possible to merge StructTypes with different names like: > > %"class.std::allocator.4" = type { i8 } > %"class.__gnu_cxx::new_allocator.5" = type { i8 } > %"class.std::allocator.0" = type { i8 } > %"class.__gnu_cxx::new_allocator.1" = type { i8 } > %"class.std::allocator.0.6" = type { i8 } > > merge