search for: mcphysreg

> On 29 Sep 2020, at 09:28, Quentin Colombet <qcolombet at apple.com> wrote: > > + Daniel who added the MCRegister class. > > Ah sorry, I replied too fast. > I mixed up MCPhysReg with MCRegister. > > I was not aware we had such class. > > From a look at it, MCRegister are essentially the same thing as Register. I am guessing that the difference is Register is used in the CodeGen layer, while MCRegister are used in the MC layer. > > Until recently Regist...

...rs at apple.com>> wrote: > > >> On 29 Sep 2020, at 09:28, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> + Daniel who added the MCRegister class. >> >> Ah sorry, I replied too fast. >> I mixed up MCPhysReg with MCRegister. >> >> I was not aware we had such class. >> >> From a look at it, MCRegister are essentially the same thing as Register. I am guessing that the difference is Register is used in the CodeGen layer, while MCRegister are used in the MC layer. >> >&g...

...gt;> >> >>> On 29 Sep 2020, at 09:28, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >>> >>> + Daniel who added the MCRegister class. >>> >>> Ah sorry, I replied too fast. >>> I mixed up MCPhysReg with MCRegister. >>> >>> I was not aware we had such class. >>> >>> From a look at it, MCRegister are essentially the same thing as Register. I am guessing that the difference is Register is used in the CodeGen layer, while MCRegister are used in the MC layer....

...Elim(MF) || SaveArgs || TRI->needsStackRealignment(MF) || MFI.hasVarSizedObjects() || MFI.isFrameAddressTaken() || MFI.hasOpaqueSPAdjustment() || @@ -850,6 +851,25 @@ MI->getOperand(3).setIsDead(); } +// FIXME: Get this from tablegen. +static ArrayRef<MCPhysReg> get64BitArgumentGPRs(CallingConv::ID CallConv, + const X86Subtarget &Subtarget) { + assert(Subtarget.is64Bit()); + + if (Subtarget.isCallingConvWin64(CallConv)) { + static const MCPhysReg GPR64ArgRegsWin64[] = { + X86::RCX, X86::RDX,...

On Tue, Sep 29, 2020 at 9:08 AM Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > Register can represent virtual or physical registers. > MCRegister can only represent physical registers. > That's what I thought, but MCRegister has some stack slot APIs. > Eventually all Register instances are replaced by a MCRegister. > What happens in that case to the

...ldn't be allocated to any vreg in function bar. Loading/saving RBP should be managed by the stack frame setup/teardown code. If it doesn't already, your allocator should filter out reserved registers (See MachineRegisterInfo::isReserved(unsigned preg)) when assigning physregs. ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); for (int i = 0; i < pregs.size(); ++i) { if (MRI->isReserved(pregs[i])) continue; // use preg... } You could also use the AllocationOrder class to simplify the task of finding valid pregs, though it does require you to use VirtRegMa...

...don't know how > to get the appropriate TargetRegisterClass (needed to call > CreateSpillStackObject). Should I instead be generating code to save > register EBP at the start of scinstal, restoring it at the end of that > function? > > Susan > > > > ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); > for (int i = 0; i < pregs.size(); ++i) { > if (MRI->isReserved(pregs[i])) > continue; > // use preg... > } > > You could also use the AllocationOrder class to simplify the task of > finding valid pregs, tho...

...ey are intentional. The important thing would be to add something like MachineRegisterInfo::setVirtRegsAfterRegalloc() and MachineRegisterInfo::getVirtRegsAfterRegalloc(). Because I would assume that we will find more examples like the following (from MachineBasicBlock): > > void addLiveIn(MCPhysReg PhysReg, LaneBitmask LaneMask = ~0u) { > LiveIns.push_back(RegisterMaskPair(PhysReg, LaneMask)); > } > > this needs to be changed to support VRegs. But if we do that change, I'd like to change it to something like this: > > void addLiveIn(unsigned Reg, LaneBitmask La...

To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad. - VirtRegs are as...

...ence we will need either a simple >> change something like the one proposed or to do what NVPTX did and just >> make our own copy of PEI. >> >> >>> >>> Problems when using virtregs throughout the backend until emit time: >>> - The MC layer is using MCPhysReg (which is an uint16_t) and would need >>> retrofitting to support virtregs >>> - VirtRegs are assumed to have a definition, physregs can appear "out of >>> thin air" in some situations like function parameters, or exception objects >>> appearing in a re...

...get the appropriate TargetRegisterClass > (needed to call CreateSpillStackObject). Should I instead be > generating code to save register EBP at the start of scinstal, > restoring it at the end of that function? > > Susan > > >> >> ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); >> for (int i = 0; i < pregs.size(); ++i) { >> if (MRI->isReserved(pregs[i])) >> continue; >> // use preg... >> } >> >> You could also use the AllocationOrder class to...

Was it the subreg lane masks / mapping that was added to address the missed coalescing? This solution is nice, but I don't think it'll work for me. I have 8-element vector registers that can be grouped into virtual super regs for bulk save/restore, and as soon as I have more than 4 in a tuple, the unsigned int used to hold the lane masks overflows and switches over to the "bit 31 set

...gress and get further experience we will need either a simple > change something like the one proposed or to do what NVPTX did and just > make our own copy of PEI. > > >> >> Problems when using virtregs throughout the backend until emit time: >> - The MC layer is using MCPhysReg (which is an uint16_t) and would need >> retrofitting to support virtregs >> - VirtRegs are assumed to have a definition, physregs can appear "out of >> thin air" in some situations like function parameters, or exception objects >> appearing in a register when goin...

----- Original Message ----- > From: "Kevin B Smith" <kevin.b.smith at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>, llvm-dev at lists.llvm.org > Sent: Thursday, December 10, 2015 2:32:36 PM > Subject: RE: [llvm-dev] Allowing virtual registers after register allocation >

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

..., as I said in my previous mail, I don't know how to get the appropriate TargetRegisterClass (needed to call CreateSpillStackObject). Should I instead be generating code to save register EBP at the start of scinstal, restoring it at the end of that function? Susan > > ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF); > for (int i = 0; i < pregs.size(); ++i) { > if (MRI->isReserved(pregs[i])) > continue; > // use preg... > } > > You could also use the AllocationOrder class to simplify the task of > finding valid pregs, tho...