search for: loadregfromstackslot

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the...

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical reg...

...that are too large to be spilled or reloaded with a single instruction. All of their bits can be accessed in word-size chunks via three sub-registers (low, high, and ext). So loading or storing one requires three instructions: one for each sub-register. For quite a while now, my implementation of loadRegFromStackSlot() and storeRegToStackSlot() has assumed that it would only receive physical registers, which makes it fairly straight-forward. They generate three memory instructions, calling TargetRegisterInfo::getSubReg() to get the sub-register operand for each of them. So it was a rude awakening when a test p...

...ge "http://llvm.org/docs/CodeGenerator.html#regAlloc_howTo" under the header "Register Allocation" and subheader "Mapping Virtual Registers to Physical Registers" the api reference "TargetRegisterInfo::storeRegToStackSlot(...)" and " TargetRegisterInfo::loadRegFromStackSlot" should be "TargetInstrInfo::storeRegToStackSlot(...)" and " TargetInstrInfo::loadRegFromStackSlot" Thanks, Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100829/8c7b6de...

I still think my answer applies that you have to modify storeRegToStackSlot()/loadRegFromStackSlot(). They decide how registers are spilled and reloaded. Nobody is stopping you from using super registers spills/reloads to implement spilling/reloading smaller registers there. - Matthias > On Jan 30, 2018, at 10:21 AM, ahmede <ahmede at ece.ubc.ca> wrote: > > Hi Quentin, > &g...

...t of >>> register and you have spilling disabled? Abort the compilation? >>> If you just want a special instruction sequence (like using a bigger >>> loads/stores for the spills) then you should be able to implement >>> that >>> in storeRegToStackSlot()/loadRegFromStackSlot(). >>> - Matthias >>>> If not, how can we implement spilling for sub-registers when stack >>>> load/stores can only operate on the super registers? Is there a way >>>> even if it is suboptimal? >>>> Thanks, >>>> Ahmed >>&g...

...o this weird issue where the register spills appear to be missing for an "if" block for some reason. For example, the original if/else blocks: --- if reg0 // storeRegToStackSlot for reg1 // do something - missing a load for reg1? else // storeRegToStackSlot for reg1 // do something // loadRegFromStackSlot for reg1 end ---- I tried looking in the LLVM spiller code but it looked like the load should have already been generated at that point. Any suggestions on what I should look for here? Thanks a lot! - Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:/...

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

...order to get and store values in memory. To assign a physical register to a virtual register present in a given operand, use ``MachineOperand::setReg(p_reg)``. To insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``, and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``. ... I tried the direct mapping as following: MachineOperand destination = MI->getOperand(0); MachineOperand offset = MI->getOperand(1); unsigned destinationReg = destination.getReg(); int64_t FrameIndex = offset.getIndex();...

Spills created at the end of the block (I assume you mean what fast regalloc does at -O0) are created long after instruction selection. In that case it sounds like your implementation of storeRegToStackSlot/loadRegFromStackSlot is broken -Matt On Tue, Oct 25, 2016 at 7:30 AM +0800, "Alex Susu via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello. I have extended the BPF back end with vector registers (inspiring from Mips MSA) - something like this:...

...lyClobber since the MI being replaced is a COPY with no EC ops. OK, I see what is happening. We don't expect foldMemoryOperand to turn a normal def into an early-clobber and vice versa. This is not easy to fix, could you file a PR, please? As a workaround, you can use a pseudo-instruction in loadRegFromStackSlot() that doesn't have the early-clobber flag. Then replace it with the real instruction in expandPostRAPseudo(). /jakob

...ed. What would you have the register allocator do when it runs out of register and you have spilling disabled? Abort the compilation? If you just want a special instruction sequence (like using a bigger loads/stores for the spills) then you should be able to implement that in storeRegToStackSlot()/loadRegFromStackSlot(). - Matthias > > If not, how can we implement spilling for sub-registers when stack load/stores can only operate on the super registers? Is there a way even if it is suboptimal? > > > Thanks, > Ahmed > _______________________________________________ > LLVM Developers m...

...he register allocator do when it runs out of > register and you have spilling disabled? Abort the compilation? > > If you just want a special instruction sequence (like using a bigger > loads/stores for the spills) then you should be able to implement that > in storeRegToStackSlot()/loadRegFromStackSlot(). > > - Matthias > >> >> If not, how can we implement spilling for sub-registers when stack >> load/stores can only operate on the super registers? Is there a way >> even if it is suboptimal? >> >> >> Thanks, >> Ahmed >> _______...

On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > 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? > Typical solution is to either re...

...order to get and store values in memory. To assign a physical register to a virtual register present in a given operand, use ``MachineOperand::setReg(p_reg)``. To insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``, and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``. ... I tried the direct mapping as following: MachineOperand destination = MI->getOperand(0); MachineOperand offset = MI->getOperand(1); unsigned destinationReg = destination.getReg(); int64_t FrameIndex = offset.getIndex();...

...ncy spill slot!"); TII->storeRegToStackSlot(*MBB, I, SReg, true, ScavengingFrameIndex, RC,TRI); MachineBasicBlock::iterator II = prior(I); TRI->eliminateFrameIndex(II, SPAdj, this); // Restore the scavenged register before its use (or first terminator). TII->loadRegFromStackSlot(*MBB, UseMI, SReg, ScavengingFrameIndex, RC, TRI); II = prior(UseMI); TRI->eliminateFrameIndex(II, SPAdj, this); }

...spilled or reloaded with a single > instruction. All of their bits can be accessed in word-size chunks via > three sub-registers (low, high, and ext). So loading or storing one > requires three instructions: one for each sub-register. > > For quite a while now, my implementation of loadRegFromStackSlot() and > storeRegToStackSlot() has assumed that it would only receive physical > registers, which makes it fairly straight-forward. They generate three > memory instructions, calling TargetRegisterInfo::getSubReg() to get the > sub-register operand for each of them. > > So it was...

Hi, I wonder if there is a way in LLVM to disable spilling a register-class while still enabling the super-registers of this register-class to be spilled. If not, how can we implement spilling for sub-registers when stack load/stores can only operate on the super registers? Is there a way even if it is suboptimal? Thanks, Ahmed

...} but it failed with this : char f() { char a; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; a++; return a; } I think something is wrong with PicoblazeInstrInfo::storeRegToStackSlot and PicoblazeInstrInfo::loadRegFromStackSlot ,since if I remove some a++ from the above c program, It can generate the right picoblaze asm code . below is my code , the whole porting with this error can by found at github : https://github.com/huangjielg/llvm-picoblaze/tree/a667350354ca1f8d23da5e76b598b8327ef239bc/lib/Target/Picoblaze /***...

...the existing machinery, is usually very short. All I need is that the spilling code would be never inserted into a live range of the FLAGS register. Is this possible? (As a side note: I tried to work-around the problem by moving the spilling code around "by hand" in TargetInstrInfoImpl::loadRegFromStackSlot / storeRegToStackSlot, but that is too late because physical registers are already allocated by then and thus it is not always possible to move the spilling code around without disturbing other register data dependencies.) Thanks, Jara -- Space--the final frontier!