similar to: [LLVMdev] jump tables

> On Sun, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > > > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > > } > > >

Dear llvmers, I am trying to insert a move instruction where both source and destination registers are physical registers. How is the code for this? I tried this one here: void PhiDeconstruction_Fer::add_move ( MachineFunction & mf, MachineBasicBlock & mbb, unsigned

Hi, again, I think I got around this problem of discovering the class of a physical register. I am using this code here: void PhiDeconstruction_Fer::add_move (MachineBasicBlock & mbb, unsigned src, unsigned dst) { MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); const MRegisterInfo * reg_info =

Thanks, Evan. Actually I've solved my problem with some hints from Dale and Anton. At least I think I've solved it. I had to add one method to TargetInstrInfo to tell me when an instruction is an indirect jump - TargetInstrInfo::tii.isIndirectJump(opcode). When that is the case, I update the jump table using: // Change jumps to go to the new basic block:

Hi, This pass is similar to the one in BreakCriticalEdges.cpp, but it works for MachineFunction's, instead of Functions. The existence of critical edges complicates many optimizations. When doing register allocation, you don't necessarily have to remove critical edges (you can use conventional SSA-form, for instance. See "Translating Out of Static Single Assignment Form. SAS

On Sun, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > Thank you, chris. But I still do not understand how to insert this move > instruction :) You call copyRegToReg, like you are already doing. What you really aren't understanding is how to pick a regclass, which is a different issue. > I have the machine function, the basic block, and the > unsigned descriptors of the

Sorry about the tardiness of my reply. My mail client has playing tricks with me. :-) I am assuming the issue has nothing to do the branch to jumptable instructions but rather the MachineJumpTableInfo associated with every MachineFunction? If so, please take a look at BranchFoldiing.cpp for an example. Evan On Aug 10, 2007, at 12:30 PM, Fernando Magno Quintao Pereira wrote: > >

On Sun, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > } > > But the getRegClass method seems to

Hi all, I have a pass to break critical edges of Machine Basic Blocks, but I just discovered a bug (when compiling code for x86). The problem is 'jumpl *%reg'. I don't know how to update the jump table for this type of instruction. The code that I had (see below) does not update the jump table, and the actual branch keeps jumping to the old basic block, instead of the new.

I would like to make a suggestion. In the LiveIntervalAnalysis class, instead of numbering the instructions in the order in which basic blocks are stored in the machine function, use the df_ext_iterator. It will order the instruction according to the dominance tree (or it seems to be doing so). There are many advantages in doing this. One of them is that, once you traverse the dominance tree

Dear guys, I am having problem to split edges correctly. Mostly because the new basic blocks are creating infinite loops. Could someone help me fixing the code below? It is creating assembly like this one below. Block LBB1_9 was inserted to break the critical edge between blocks LBB1_3 and LBB1_8. But it changes the semantics of the original program, because, before, LBB1_8 was falling

On Thu, 21 Jun 2007, Fernando Magno Quintao Pereira wrote: > I would like to make a suggestion. In the LiveIntervalAnalysis class, > instead of numbering the instructions in the order in which basic blocks > are stored in the machine function, use the df_ext_iterator. It will order > the instruction according to the dominance tree (or it seems to be doing > so). There are many

Nice idea. Please also try using SmallPtrSet (with a sufficiently large size) instead of std::set for traversal after everything is working. Using std::set can really hurt compile time in case of large basic block numbers. Is there a way to dynamically adjust "SmallSize" based on number of basic blocks in the function? Evan On Jun 21, 2007, at 10:20 PM, Fernando Magno Quintao

Hi, Just my two cents: If I recall correctly, in some papers on the linear scan register allocation people described that they tried different orderings for instruction numbering, e.g. including DFS or based on the loop nesting levels, etc. There was no clear winner though. But let's see the numbers anyway. May be it really brings some improvements. -Roman Chris Lattner wrote: > On

The problem is that you are inserting block 9 in the wrong spot. mf.getLastBlock() returns the block with the greatest number which may have nothing to do with the ordering. Why not use the end iterator (mf.end) to insert? -Tanya On Sat, 8 Jul 2006, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I am having problem to split edges correctly. Mostly because the new

Hi, I am able to remove the critical edges now. I only had to insert the line below in PPCTargetmachine.cpp. PM.add(createBreakCriticalEdgesPass()); However, it does not remove all the critical edges. I am getting a very weird dataflow graph (even without the Break Critical edges pass). The dataflow generated by MachineFunction::dump() for the program below is given here:

Dear guys, I want to coalesce some copies, and I would like to know if there is any method that I can call, like JoinCopy from the old (LLVM 1.9) LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM 2.1), but I do not want to call this analysis, as I have my own. basically, I can determine that two virtuals do not overlap, and I know that it is safe to join them. In

On 11/23/07, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Hi, Sanjiv, > > those passes operate on the whole machine function. Each machine > function contains many basic blocks. If a program has many functions, the > register allocator will be called as many times, i.e it does not do > interprocedural allocation. > > best, > >

Dear LLVM'ers (or whatever name you will soon have), I want to create a pass option, that I could pass at command line, and that would be visible among many different MachineFunction passes. It would be something like the join-liveintervals used in LiveIntervalAnalysis, but I want my option to be visible among many passes, and not only one. I browsed the documentation, but I did not

Thanks again. One more question here: Since the regalloc works once per function, do I stil have access to the Call graph? Just saving information between regalloc passes for different functions may not be enough for my case. I will need to maintain the regalloc info of various passes in the call graph order. Anyways thanks for your inputs. I will get back if I need to learn more. Sanjiv On Nov