similar to: Disable spilling sub-registers in LLVM

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

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

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

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

> 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

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,

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:

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 people, the LinearScan register allocator tries to use same register for both live intervals, if the new interval is defined by a register copy whose destination reg is compatible with the source register. This is ok. However, this "check for compatibility" is wrongly done IMHO. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only

Given an architecture with two classes of registers: A is general purpose and has an "adequate" number of registers, and C which is special purpose and has very few (e.g. one) register. There are cheap instructions that directly copy from C to A and vice versa. If we need another C register and they are all live, we need to spill one. Currently as far as I can tell, the only way to

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

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

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

On Sep 13, 2010, at 6:59 AM, Carlos Sánchez de La Lama wrote: > Hi people, > > the LinearScan register allocator tries to use same register for both > live intervals, if the new interval is defined by a register copy > whose destination reg is compatible with the source register. This is > ok. However, this "check for compatibility" is wrongly done IMHO. >

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

Hello. I have extended the BPF back end with vector registers (inspiring from Mips MSA) - something like this: def MSA128D: RegisterClass<"Connex", [v128i16], 32, (sequence "Wh%u", 0, 31)>; I also added vector store and load instructions in the style of Mips MSA - see

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

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