similar to: Missing TerminatorInst in the trunk no. 350084

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,

+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.

Hi, I'm curious how it would affect the getTerminator() method of a basic block? 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

> 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

On Fri, May 18, 2018 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 >

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 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 Thu, May 17, 2018 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > 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

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

Hi LLVMers, I can't figure out why these errors exits: ------------------------- llvm[2]: Linking Debug executable opt c:/projects/build/MinGW/llvm-4-1/Debug/lib/LLVMProfilePaths.o(.text$_ZN4llvm10BranchInstC1EPNS_10BasicBlockES2_+0x52): In function `ZN9__gnu_cxx13new_allocatorISt13_Rb_tree_nodeISt4pairIKPN4llvm8FunctionEPNS3_5GraphEEEE10deallocateEPSA_j':

Are there any known issues with the 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

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

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

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

Hi all, I was trying to implement an obfuscation tool for C-code on the basis of LLVM. I got a prototype of the simple obfuscation transformation which converting control flow graph to something like a state machine. I am not sure I will have time to work on extending further this tool with new transformations like opaque predicates and decided to put here source code I have by now with hope