similar to: [LLVMdev] [Website] Error in the documentation on the website.

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

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

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:

Hi folks, I'm running into 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

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, > >

Does anybody have any tips for generating spills/reloads for large non-vector registers? I'm working on a back end for a DSP architecture that has accumulator registers 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:

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? >

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > 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

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will

> On Jan 29, 2018, at 1:20 PM, ahmede via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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. What would you have the register allocator do when it runs out of register and you have spilling disabled? Abort the

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

Hello, I am developing compiler for the 8-bit PicoBlaze processor in LLVM 2.9. The problem at hand is that the stack spilling code in this architecture modifies the machine FLAGS register (i.e. globally visible state). The LLVM core code does not know about this 'feature' and happily inserts spilling code anywhere it wants, thus (potentially) corrupting live FLAGS. Practically, the FLAGS

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively used in arithmetic operations but no stack

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

Hi Brian, +1 on what Nemanja said: specifying large register classes is the key. More details here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html <http://lists.llvm.org/pipermail/llvm-dev/2019-December/137700.html> Cheers, -Quentin > On Sep 9, 2020, at 11:13 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On PowerPC, we

I'm confused as to the logic used in the register scavenger when it cannot find a free register. I would think that it would want to free up the emergency spill slot immediately after it's use, because otherwise there is a chance of needing to use the emergency slot again and not be able to. Instead it tries to restore it only right before register it is freeing up. Maybe I'm

Hi Ahmed, If you access your values with sub-registers indices, IIRC the inline spiller will spill the super register. If you access your values directly (via sub-regclass), then the spiller uses this class. Basically what I am saying is the spiller spills the value that contains the accesses. E.g., = v; will spill v = v.sub1; will spill v too, but v is a super register in that case. Cheers,

Hi, In the context of MachineCode custom inserter, I'm trying to enforce the mapping of virtual register to a physical one. According to the documentation https://llvm.org/docs/CodeGenerator.html#mapping-virtual-registers-to-physical-registers There are two ways: the direct one and the indirect ones. The indirect ones refer VirtRegMap class that I've never found. So I tried the direct

Hello, all, I want to implement the register allocation algorithm described in the paper "Register Allocation via Coloring of Chordal Graphs, APLAS'05" in LLVM. This is a graph coloring algorithm that can find an optimal coloring of the interference graph in most of the cases. I've downloaded LLVM last week, and started studying the code. Basically, I have to implement: 1) A

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction