similar to: [LLVMdev] MRegisterInfo::storeRegToStackSlot question

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

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 for the copy. The target can choose to ignore this if it

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

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,

On Tue, 23 May 2006, Vladimir Prus wrote: > right now, LLVM does register spilling by: > > 1. Creating stack object > 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot > 3. At later stage, frame indices are replaced by calling to > MRegisterInfo::eliminateFrameIndex. > > This works for me, but there's slight problem. The target does not have

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

The docs for the above-mentioned function say: This method may modify or replace the specified instruction, as long as it keeps the iterator pointing the the finished product. What does it mean to "keep an interator". Was "invalidates the iterator" intended, so something else. Another question, is how do I really replace the instruction. The operator= is private

Hi Lang. Thank you. I added pseudo-instructions for spill/reloads and expanded it in expandPostRAPseudo. Regards, Dmitriy. 04.03.2013 8:24, Lang Hames wrote: > 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

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.

This code or subtle variations of it appears in multiple targets. It tries to convert from a register to a register class using getRegClass, but getRegClass is really supposed to take a register class enum value and get the register class object for it. It doesn't convert a register to a class. In fact there's not always a single or canonical class for a given register. What is the right

I'm looking at an issue where we want a particular pseudo-instruction to choose from a set of registers that is not included in the existing set of RegisterClass definitions. More concretely, there is a RegisterClass in ARMRegisterInfo.td defined as def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> { let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)]; let

On Tue, May 17, 2011 at 2:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > > > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: > >> What you can do instead is: > >> > >> 1) Just use virtual registers and skip register allocation, or > >> > >> 2) Allocate to a

On May 17, 2011, at 2:10 PM, Justin Holewinski wrote: > I plan on eventually implementing both and seeing which works best for different types of input. > > If virtual registers are used, how do you disable final register allocation in the back-end? If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.

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. The COPY instruction handles subreg operations with less

Hi, I'm implementing storeRegToStackSlot() and, in order to store some specific registers (floating point regs and address regs) I've to copy them to more standard regs and copy these last ones to the slot. I tried to generate instructions that use physical registers, but by doing that I overwrote registers already assigned by the register allocator. Is it possible to use virtual registers

On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > Hi, > I'm implementing storeRegToStackSlot() and, in order to store some > specific registers (floating point regs and address regs) I've to > copy them to more standard regs and copy these last ones to the slot. > I tried to generate instructions that use physical registers, but by > doing that I overwrote

Dan Gohman a écrit : > On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > > >> Hi, >> I'm implementing storeRegToStackSlot() and, in order to store some >> specific registers (floating point regs and address regs) I've to >> copy them to more standard regs and copy these last ones to the slot. >> I tried to generate instructions that use

I start my porting for picoblaze,the soft cpu for fpga ,which is designed by XILINX from MSP430 porting . After some day's work , somethinig looks good , for it can generate for some simple C program: eg : int f1(int a) { return a+1; } but it failed with this : char f() { char a; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++;

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: >> What you can do instead is: >> >> 1) Just use virtual registers and skip register allocation, or >> >> 2) Allocate to a small register file, implement memory operand folding, and pretend that spill slots are registers. >> >> /jakob >>