similar to: [LLVMdev] Doubt in PHI node elimination

Sachin.Punyani at microchip.com wrote: > > Hi, > > > > In PHI node elimination pass to insert the copy in the predecessor > block, there is a check if terminator is not an invoke instruction > then place the copy there only. However for invoke terminator > instruction a safe position is located for copy insertion. > > > > My doubt is why is this safe

On Jul 3, 2009, at 4:01 AM, Sanjiv Gupta wrote: > Sachin.Punyani at microchip.com wrote: >> >> Hi, >> >> >> >> In PHI node elimination pass to insert the copy in the predecessor >> block, there is a check if terminator is not an invoke instruction >> then place the copy there only. However for invoke terminator >> instruction a safe

Hi, The PHI elimination pass calls the function copyRegToReg for copy placement and then later tries to setkill to the temporary virtual register used in copy placement. For this setkill action it looks only in one instruction (last instruction for copyRegToReg) for virtual register with no use. My target has only one register and I can't do copyRegToReg in one instruction only. So I

Hey, guys, I am creating some move instructions with MRegisterInfo::copyRegToReg. How do I get a pointer to the instruction that I just created? Is there a way to do something like: // mbb is MachineBasicBlock, reg_info is MRegisterInfo MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); reg_info->copyRegToReg(mbb, iter, dst, src, rc); iter--; (???) MachineInstr *

Aye, between all current register allocators the 'AU.addRequiredID(PHIEliminationID);' will cause phi's to be eliminated to copies, but this misses the point of my question. What I am asking, is how does stack know that the value of the variable which the resulting value of the phi is currently allocated at. For instance take the instruction: Machine Basic Block (mbb) 12 reg16666 =

There is nothing that currently handles this properly, as far as I know. If you have a phi c = phi(a, b) where a, b and c are all assigned distinct stack slots, then copies must be inserted in the predecessor. If registers have already been allocated, then this memory copy might require a temporary register (unless you're on an architecture like x86 that lets you do memory-to-memory copies

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >> in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' >> parameter, that is not documented. >> >> Can somebody explain what does it mean? > > Basically, it gives the target more information about the spill. In > particular, it specifies the register class to use

Hi All. I'm writing storeRegToStackSlot and loadFromStackSlot function for my Target. This Target can store/load one byte (not all word) from FrameIndex. If I need to store 16 bit register I will must to split it to two instruction like this: BuildMI(MBB, MI, dl, get(Z80::LD8xmr)) .addFrameIndex(FrameIndex).addImm(0) .addReg(SrcReg, 0, Z80::subreg_lo); BuildMI(MBB, MI, dl,

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

Thank you for your reply! > Every MachineBasicBlock has a list of successors; you can access it with > the successors() accessor. That's what you should be using for any CFG > analysis. I am aware of these methods of class MachineBasicBlock, which allows one to access a MachineBasicBlock's successors and predecessors in the CFG. But the CFG itself may no longer be valid if a

The allocator you are building, is it the Hack's and Goos's polynomial time algorithm? On Tue, Oct 5, 2010 at 7:14 PM, Cameron Zwarich <zwarich at apple.com> wrote: > There is nothing that currently handles this properly, as far as I know. If you have a phi > > c = phi(a, b) > > where a, b and c are all assigned distinct stack slots, then copies must be inserted in

MachineBasicBlock allows for multiple terminators. Unconditional branches and returns are marked as terminators; the MIPS backend also marks conditional branches as terminators. The MachineBasicBlock then has a helper function getFirstTerminator which iterates from the first terminator to the end of the MBB. So it seems to me that an MBB is a kind of superblock, single entrance and multiple side

On Sep 5, 2014, at 10:21 AM, Juergen Ributzka <juergen at apple.com> wrote: > clearKillFlags seems a little "overkill" to me. In this case you could just simply transfer the value of the kill flag from the SrcReg to the DstReg. We are extending the live-range of SrcReg. I do not see how you could relate that to the kill flag of DstReg. Therefore, I still think, this is the

> 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); > > } > > >

For spilling, I plan to use the Hack-Braun generalization of the furthest-first heuristic for SSA: http://pp.info.uni-karlsruhe.de/uploads/publikationen/braun09cc.pdf For coloring, there are a few different approaches you can take, e.g. dominator tree scan, puzzle-solving, or a modified graph coloring / coalescing heuristic like IRC. The best quality for the least amount of implementation effort

I'm working on a target based on the MIPS target, and when I copy f64 values into 32 bit registers for calling functions, I need the operation to work on a of 32 bit registers (because the language I'm translating to isn't actually mips). I've been looking at how to do this, but I haven't been able to figure it out. Since the Mips target code is still really close to mine,

On Jun 15, 2010, at 2:48 PM, Jakob Stoklund Olesen wrote: > I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer.

Hi Dmitriy, As you've seen our current spill code assumes that spill/reloads are single instructions. I think the best way to work around this is to introduce load/store pseudo-instructions and expand these after register allocation. Cheers, Lang. On Sat, Feb 23, 2013 at 12:15 AM, Dmitriy Limonov <earl at excluzive.ws> wrote: > Hi All. > > I'm writing

At the moment, phi elimination happens before register allocation, so there can be no phis between memory locations. Cameron On Oct 5, 2010, at 4:19 PM, Jeff Kunkel wrote: > When doing phi elimination, does one have to communicate with the > stack space at all? The problem I see is two distinctly different > registers may have two distinctly different stack spaces. When these >

copyRegToReg() always insert the move instruction before "iter". Just use prior(iter) after the insertion to reference the newly created move instruction. Evan On Feb 21, 2007, at 11:17 PM, Fernando Magno Quintao Pereira wrote: > > Hey, guys, I am creating some move instructions with > MRegisterInfo::copyRegToReg. How do I get a pointer to the instruction > that I just