search for: isreserved

Dear R-core Team, As Thomas Lumley pointed out in one of his e-mails one can use commandArgs() to get a copy of the command line arguments supplied when R session was invoked and then use grep to extract parameters of interest. His solution works very well if the custom options are passed by names, e.g. --my-option=value, but what if one wants to pass parameters by their positions. Then it's

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where PhysReg may be a reserved physical register. Specificially, RegAllocPBQP::finalizeAlloc() may select a physical register thusly: const TargetRegisterClass &RC = *MRI.getRegClass(LI.reg); P...

...er on x86 (hence its automatic appearance in your code), and shouldn'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...

...matic appearance > in your code), and shouldn'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. > > > I AM filtering out reserved registers. > > I am not allocating RBP in function bar, I am allocating EBP, because it > is NOT in the list of reserved registers for function bar. > > Neither register RBP nor register EBP is s...

...ode), and shouldn'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. > > I AM filtering out reserved registers. > > I am not allocating RBP in function bar, I am allocating EBP, > because it is NOT in the list of reserved registers for function bar. > > Neither register RBP no...

...6 are all taken), so I > added: > ``` > --- a/llvm/lib/MCA/HardwareUnits/ResourceManager.cpp > +++ b/llvm/lib/MCA/HardwareUnits/ResourceManager.cpp > @@ -292,7 +292,7 @@ void ResourceManager::issueInstruction( > ResourceState &RS = *Resources[Index]; > > - if (!R.second.isReserved()) { > + if (!R.second.isReserved() && RS.isReady()) { > ResourceRef Pipe = selectPipe(R.first); > use(Pipe); > BusyResources[Pipe] += CS.size(); > ``` > which is probably the cause of that weird behavior I reported. > > > > I’m also somewhat curious about what...

> On May 9, 2020, at 5:12 PM, Andrea Di Biagio via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The llvm scheduling model is quite simple and doesn't allow mca to accurately simulate the execution of individual uOPs. That limitation is sort-of acceptable if you consider how the scheduling model framework was originally designed with a different goal in mind (i.e. machine

...number -I<llvm-install>/llvm/include -I<llvm-src/llvm/include -DL_muldc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../../../src/llvm-gcc-4.2/gcc/libgcc2.c -o libgcc/./_muldc3.o cc1: <llvm-src>/llvm/lib/CodeGen/RegisterScavenging.cpp:273: void llvm::RegScavenger::forward(): Assertion `(isReserved(Reg) || isUnused(Reg) || IsImpDef || isImplicitlyDefined(Reg) || isLiveInButUnusedBefore(Reg, MI, MBB, TRI, MRI)) && "Re-defining a live register!"' failed. ../../../../src/llvm-gcc-4.2/gcc/libgcc2.c:1914: internal compiler error: Aborted Please submit a full bug report, with...

...onst MachineInstr &MI) const { + const MachineOperand &Op2 = MI.getOperand(2); + const MachineOperand &Op3 = MI.getOperand(3); + + return ((Op3.getType() == MachineOperand::MO_Immediate) && + (Op3.getImm() == 0) && + (Op2.isKill() && !MRI->isReserved(Op2.getReg()))); +} + +bool X86FoldRedundantInserts::isValidMOVSS(const MachineInstr &MI) const { + const MachineOperand &MO = MI.getOperand(2); + unsigned Reg = MO.getReg(); + + return !MRI->isReserved(Reg) && MO.isKill(); +} + +bool X86FoldRedundantInserts::isValidCandidate(...

...illedCS1GPRs[i]; // Don't spill high register if the function is thumb1 - if (!AFI->isThumb1OnlyFunction() || + if (!AFI->isThumbFunction() || isARMLowRegister(Reg) || Reg == ARM::LR) { MRI.setPhysRegUsed(Reg); if (!MRI.isReserved(Reg)) On Tue, Oct 15, 2013 at 10:15 AM, Andrea Mucignat <andrea at nestlabs.com>wrote: > Umesh, > > From Target/ARM/ARMRegisterInfo.td, it looks like FP for Thumb should be > r7 instead of r11. > > // Register classes. > // > // pc == Program Counter > // lr =...

.... The way the ARM back-end does is to treat R9 as a special register from birth, like the frame pointer, and use it to calculate register pressure and to allow it to be allocated or not. I agree this is not the same as doing it with *any* register, but it shouldn't be particularly hard to add isReserved(Reg), add it to the Reserved list, and avoid it during allocation on a per-module (not function) granularity. We'd have to do that on all targets, yes, it won't be easy, but it should be doable and the register allocator already respects a restricted list of reserved registers dynamically....

On 28 March 2014 10:17, Chandler Carruth <chandlerc at google.com> wrote: > This has been the long standing historical objection to the feature. It is a > *really* invasive change to the register allocator to plumb this kind of > register reservation through it. Do you mean only the reserved part or the general named register idea? About reserving registers, we already have the

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

...ic > appearance in your code), and shouldn'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. I AM filtering out reserved registers. I am not allocating RBP in function bar, I am allocating EBP, because it is NOT in the list of reserved registers for function bar. Neither register RBP nor register EBP is saved/restored across the call from...

Hi Curt/all, Would it be a bad idea to bug Julian again to add us here? http://www.wxwindows.org/contrib2.htm We are already in the Community pages, but wxPerl/wxPython/wxLua/etc are also on the Contributions page. -- dave

Is the new wxruby-users@rubyforge.org mailing list subscription-moderated? I have subscribed and confirmed my subscription, but have not been getting mails. -- dave