similar to: [LLVMdev] deleting or replacing a MachineInst

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] deleting or replacing a MachineInst"

2015 Feb 11
2
[LLVMdev] deleting or replacing a MachineInst
This seems a very natural approach but I probably am having a trouble with the iterator invalidation. However, looking at other peephole optimizers passes, I couldn't see how to do this: #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for
2015 Feb 11
2
[LLVMdev] deleting or replacing a MachineInst
There are 11 BuildMI() functions in MachineInstrBuilder.h including four using the iterator and one using an instruction. But I just don't think that's it. The creation of the new instruction works fine (works fine with OldMI as well) and the new instruction is present in the assembly output. The problem is removing the old instruction correctly. > The loop header needs to be
2015 Feb 11
2
[LLVMdev] deleting or replacing a MachineInst
I made the change to the BuildMI() call. Again, I don't think that matters. #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, OldMI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) I didn't completely understand your other proposed change: ​ for (MachineBasicBlock::iterator MBBI = MBB->begin();
2008 Jan 11
2
[LLVMdev] Classifying Operands & Def/Use Chains
Is there any way to discover whether a particular operand of a MachineInst participates in addressing? That is, if the MachineInst references memory, can I tell, given an operand, whether that operand is part of the address calculation for the instruction? Also, is there any reasonable way to get the set of machine instructions to which the output(s) of some machine instruction flows? The
2010 Aug 29
0
[LLVMdev] [Query] Programming Register Allocation
On Sat, Aug 28, 2010 at 16:20:42 -0400, Jeff Kunkel wrote: > What I need to know is how to access the machine register classes. Also, I > need to know which virtual register is to be mapped into each specific > register class. I assume there is type information on the registers. I need > to know how to access it. MachineRegisterInfo::getRegClass will give you the TargetRegisterClass
2010 Aug 29
1
[LLVMdev] [Query] Programming Register Allocation
Thanks for the information. I still don't know how do I partition registers into different classes from the virtual registers? For instance, I have the function who which iterates over the instructions, but I don't know how to write the function which returns the different register class. void RAOptimal::Gather(MachineFunction &Fn) { // Gather just iterates over the blocks,
2010 Aug 28
2
[LLVMdev] [Query] Programming Register Allocation
So I have a good understanding of what and how I want to do in the abstract sense. I am starting to gain a feel for the code base, and I see that I may have a allocator up and running much faster than I once thought thanks to the easy interfaces. What I need to know is how to access the machine register classes. Also, I need to know which virtual register is to be mapped into each specific
2008 Jan 11
0
[LLVMdev] Classifying Operands & Def/Use Chains
On Jan 11, 2008, at 2:00 PM, David Greene wrote: > Is there any way to discover whether a particular operand of a > MachineInst > participates in addressing? That is, if the MachineInst references > memory, > can I tell, given an operand, whether that operand is part of the > address > calculation for the instruction? Nope, not that I know of. > Also, is there any
2020 Oct 06
2
Optimizing assembly generated for tail call
Hello, I recently found that LLVM generates sub-optimal assembly for a tail call optimization case. Below is an example (https://godbolt.org/z/ao15xE): > void g1(); > void g2(); > void f(bool v) { > if (v) { > g1(); > } else { > g2(); > } > } > The assembly generated is as follow: > f(bool): # @f(bool) > testb %dil, %dil > je .LBB0_2 >
2015 Jan 11
3
[LLVMdev] [RFC] [PATCH] add tail call optimization to thumb1-only targets
Hello, find enclosed a first patch for adding tail call optimizations for thumb1 targets. I assume that this list is the right place for publishing patches for review? Since this is my first proposal for LLVM, I'd very much appreciate your feedback. What the patch is meant to do: For Tail calls identified during DAG generation, the target address will be loaded into a register by use
2015 Apr 28
2
[LLVMdev] Lowering intrinsic that return an int1
Hi all, I'm playing with intrinsics and I was wondering how to lower an intrinsic that should return, for example, an int1? More precisely, how to return the value when working with MachineInst? First, I have defined an instrinsic in "Intrinsics.td": _def int_antivm : Intrinsic<[llvm_i1_ty], [], [], "llvm.antivm">;_ Then I want to lower it in the X86 backend,
2018 Mar 06
2
[RFC] llvm-mca: a static performance analysis tool
On Tue, Mar 6, 2018 at 5:55 AM, Andrew Trick via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com> wrote: > > > > On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at
2018 Mar 06
0
[RFC] llvm-mca: a static performance analysis tool
> On Mar 6, 2018, at 4:20 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. > > Personally, I
2009 Nov 14
5
[LLVMdev] next
In many places there is code that looks like: MBBI = next(MBBI); In C++0X there is a std::next that is likely to be in scope when these calls are made. And due to ADL the above call becomes ambiguous: llvm::next or std::next? I recommend: MBBI = llvm::next(MBBI); -Howard
2010 Nov 13
1
[LLVMdev] problem with llvm reverse iterator
Hi, I am writing an llvm pass wherein I require to iterate MachineBasicBlocks in reverse. The ilist reverse_iterator is not functioning as expected. Nor is the ilist iterator working in reverse (although -- operator is overloaded to do so). for (MachineFunction::iterator MBBI = mf_->end(), E = mf_->begin();MBBI != E; --MBBI) { MachineBasicBlock *MBB = MBBI;
2015 Sep 08
4
Inserting MachineInstr's
Hi, I have a task to complete and I'm getting stuck. I can't find anything comparable in the documentation. The shortest explanation I can give is as follows: I need to use double-precision floating point values for floating-point multiplies. I'll not go into why: That would take the discussion away from the essential problem. E.g. Replace: fmuls %f20,%f21,%f8 with the
2010 Nov 05
4
[LLVMdev] Basic block liveouts
Is there an easy way to obtain all liveout variables of a basic block? Liveins can be found for each MachineBasicBlock, but I can only find liveouts for the whole function, at MachineRegisterInfo. Do I need to find them out manually?
2009 Nov 16
4
[LLVMdev] next
On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > >> In many places there is code that looks like: >> >> MBBI = next(MBBI); >> >> In C++0X there is a std::next that is likely to be in scope when these >> calls are made. And due to ADL the above call becomes ambiguous: >>
2010 Nov 05
0
[LLVMdev] Basic block liveouts
Because I feel bad for giving a non-answer: An easy way to find if a virtual register is alive after the basic block is to While iterating over the virtual registers - Check to see if the virtual register's "next" value exists outside of the basic block. for instance: std::vector<unsigned> findLiveOut( MachineBasicBlock * mbb ) { std::vector<unsigned> liveout; for(
2009 Nov 16
0
[LLVMdev] next
On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > In many places there is code that looks like: > > MBBI = next(MBBI); > > In C++0X there is a std::next that is likely to be in scope when these > calls are made. And due to ADL the above call becomes ambiguous: > llvm::next or std::next? > > I recommend: > > MBBI = llvm::next(MBBI); > > -Howard