search for: getlargestlegalsuperclass

...eed to 'let Size = 4' if you go with > untyped). > > Your implementation in copyPhysReg is the final word on what it means > to copy between registers in this class. > > The register class will not be used automatically without permission > from your implementation of getLargestLegalSuperClass. This function > should not allow normal GPR registers to be inflated to the GPR+CR > super-class because not all registers in that class have enough > bits. > > X86RegisterInfo::getLargestLegalSuperClass() does something similar > with the GR8_NOREX register class to work around...

...a default spill size, so you may need to 'let Size = 4' if you go with untyped). Your implementation in copyPhysReg is the final word on what it means to copy between registers in this class. The register class will not be used automatically without permission from your implementation of getLargestLegalSuperClass. This function should not allow normal GPR registers to be inflated to the GPR+CR super-class because not all registers in that class have enough bits. X86RegisterInfo::getLargestLegalSuperClass() does something similar with the GR8_NOREX register class to work around some awkward x86 encoding iss...

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

...7700.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 implemented support for spilling GPR registers to vector registers. Essentially, it requires specifying the correct register class in `getLargestLegalSuperClass()` as well as `storeRegToStackSlot()/loadRegFromStackSlot()`. You can see what is controlled with the `EnableGPRToVecSpills` option. > > If you also want to use this method for spilling callee-saved registers to other registers, you can do what we do on PPC in `assignCalleeSavedSpillSlots()`...

...> need to 'let Size = 4' if you go with untyped). > > Your implementation in copyPhysReg is the final word on what it means to > copy between registers in this class. > > The register class will not be used automatically without permission from > your implementation of getLargestLegalSuperClass. This function should not > allow normal GPR registers to be inflated to the GPR+CR super-class because > not all registers in that class have enough bits. > > X86RegisterInfo::getLargestLegalSuperClass() does something similar with > the GR8_NOREX register class to work around some...

Hi Tim, I wonder if you could help me with the following, even if just giving some pointers about where to look. I previously posted a similar question in the mailing list, but unfortunately I have not received a reply. This is the subject: I want to reduce the number of register spills to the stack that are created around storeRegToStackSlot and loadRegFromStackSlot In order to do so, I can

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

...uperclass relationships. You only have to supply the sets. Define the Mips16 instructions as independent instructions, and use the restricted register class to constrain their inputs and outputs. Set the restricted register class as the legal regclass for i32, but make sure you implement the TRI::getLargestLegalSuperClass() target hook. It should return the full CPURegs register class as a legal super-class. The register allocator will then use those registers for live ranges that are only used by copy instructions. Such live ranges are created by live range splitting, so the remaining registers are effectively used...

...ut the key point here is that PTR is a subset of DREGS, so cross class copies are perfectly allowed. One of the 2 registers in the PTR regclass is reserved for the frame pointer, leaving only one register to access both x and y[i] in the code above, which seems to confuse the regalloc. Implementing getLargestLegalSuperClass() sort of helped for simpler functions, but not for this one. This code can be register-allocted if the addresses of both x and y[i] are cross class copied to DREGS registers to temporarily store these values and then when required copied back to the the register in PTR to access them in memory. A...

...hat depends. The register allocator can spill across register classes, but it calls the functionality "live range splitting" and "register class inflation". Here's how you enable it: - Define a union register class that contains both CPU64Regs and ACRegs. - Implement TRI::getLargestLegalSuperClass(), and return the new union register class when asked about CPU64Regs or ACRegs (or their sub-classes). - Teach TII::copyPhysReg() to handle the cross-class copies. - Teach TII::storeRegToStackSlot() to constrain the register class to CPU64Regs when asked to spill a virtual register from the unio...

I'm working on the mips16. Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, it is a compressed form of the MIPS32 instruction set, though not all instructions are supported. Most of the same opcodes and formats are present though sometimes with some restriction. (The micro mips architecture is a true 16 bit compressed form of MIps32 though also with some

On Mon, Nov 4, 2019 at 12:18 PM Quentin Colombet <qcolombet at apple.com> wrote: > Hi Alex, > > Thanks for reporting this. > Wei worked on the hoisting optimization. > > @Wei, could you work with Alex to see what is the problem. > > Cheers, > -Quentin > > > On Nov 3, 2019, at 5:20 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >

Jakob Stoklund Olesen <jolesen at apple.com> writes: >> What happens if the result of the above pattern using COPY_TO_REGCLASS >> is spilled? Will we get a 64-bit store or a 128-bit store? > > This behavior isn't affected by the change. FR64 registers are spilled > with 64-bit stores, and VR128 registers are spilled with 128-bit > stores. > > When the

Hi Jakob, I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries. One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before you call scavengeRegister, even if it turns out you only need one. Having an extra stack slot might not be

...e key point here is that PTR is a subset of DREGS, so cross class copies are perfectly allowed. > One of the 2 registers in the PTR regclass is reserved for the frame pointer, leaving only one register to access both x and y[i] in the code above, which seems to confuse the regalloc. Implementing getLargestLegalSuperClass() sort of helped for simpler functions, but not for this one. > This code can be register-allocted if the addresses of both x and y[i] are cross class copied to DREGS registers to temporarily store these values and then when required copied back to the the register in PTR to access them in memo...

...p a lot. When not using sub-registers, the optimization does exist. For example, if you have a VR128 virtual register, but all the instructions using it only require FR32, MRI->recomputeRegClass() will figure it out, and downgrade to FR32. It gets permission to do this because X86RegisterInfo::getLargestLegalSuperClass(VR128) returns FR32. /jakob

On Jul 26, 2012, at 9:43 AM, dag at cray.com wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1,

So I've been designing an experimental 6502 backend for LLVM. Link: <https://github.com/beholdnec/llvm-m6502> The 6502 only has a few registers, one accumulator and two indexes, none of which are large enough to hold an absolute pointer. Because of this, the backend really tests the power of LLVM's register allocator (RA). I've made a change to the RA that might be of interest

...llocator can spill across register classes, but it calls the > functionality "live range splitting" and "register class inflation". Here's > how you enable it: > > - Define a union register class that contains both CPU64Regs and ACRegs. > > - Implement TRI::getLargestLegalSuperClass(), and return the new union > register class when asked about CPU64Regs or ACRegs (or their sub-classes). > > - Teach TII::copyPhysReg() to handle the cross-class copies. > > - Teach TII::storeRegToStackSlot() to constrain the register class to > CPU64Regs when asked to spill a vi...

I've mentioned my sneaky plans to target the MOS6502 here before. The big issue I think is that a lot of instructions don't really have a choice for output register. It all just goes into the accumulator, X index, or Y index based on the specific instruction. So, my question is, when I'm defining my ins, outs and registers for these instructions, is it going to be a problem that