similar to: RFC: Removing TerminatorInst, simplifying calls

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

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

+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

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

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

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

(and FWIW, I'm currently trying to finish the patch that makes this a reality... mostly hard because it has to unwind a loooot of complexity we've built up due to not having this) On Sat, Nov 3, 2018 at 5:47 PM Jeremy Lakeman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html > > TLDR; CallInst & InvokeInst

I've been out of the loop for awhile. Is there an email thread about the "removing terminators as a thing" concept? On Wed, Oct 31, 2018, 10:13 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org wrote: > FWIW, I’m generally supporting of this direction, and would love to see > asm goto support. > > Could you compare and contrast asmbr to a couple other

On Apr 14, 2009, at 1:49 PM, Luke Dalessandro wrote: > > On Apr 14, 2009, at 12:48 PM, Brice Lin wrote: > >> I just read the LLVM Programmer's Manual, which mentions (but >> specifically does not include any details of) the InstVisitor >> template. Could someone please provide an example of how to use this >> template to find (as an example) all CallSites for

I just read the LLVM Programmer's Manual, which mentions (but specifically does not include any details of) the InstVisitor template. Could someone please provide an example of how to use this template to find (as an example) all CallSites for the function strcpy? Thanks, Brice Lin

Hello, In my module I have functions: a b c f3 calls "a" f2 calls "a" f1 calls "b" I would like to modify a CallInst in the f2. Now it calls "a", but I want changed it to "c". When loop over the instructions of the f2, I can get a CallInst to be modified, then I use "setName" to changed it to "c". Problem is, since

I searched the doxygen documentation and could not find a solution to my task: In a ModulePass running at EP_OptimizerLast, if I have a function F like in: bool Foo:runOnModule(Module &M) { LLVMContext &C = M.getContext(); for (auto &F : M) { // magic here if I want to know from which function (callee) each function is called - how can I do this? (so that I e.g. have

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in

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, Recently, I am working on some information collection on the machine instruction (MachineInstr) level. But, sometimes, I need check the corresponding IR level instruction of the a machine instruction. When visiting a machine instruction which is a call (MachineInstr::isCall()), I need to check the arguments of this call site. I know that the CallSite class provides good facility for this

On Apr 14, 2009, at 12:48 PM, Brice Lin wrote: > I just read the LLVM Programmer's Manual, which mentions (but > specifically does not include any details of) the InstVisitor > template. Could someone please provide an example of how to use this > template to find (as an example) all CallSites for the function > strcpy? If this is really what you want to do, then the easiest