search for: isphysicalregist

...-regalloc=linearscan" to provoke > the error). Yes, that's exactly what I meant... thanks for reading my mind! :) It looks like this is where things start to go downhill (LiveIntervals.cpp:559): LiveIntervals::Interval::Interval(unsigned r) : reg(r), weight((MRegisterInfo::isPhysicalRegister(r) ? std::numeric_limits<float>::infinity() : 0.0F)) { For a physical register (EDX in this case) it appears that the interval is being created, but gets a 0 weight instead of an infinity weight. This implies that the MRegisterInfo::isPhysicalRegister might have an issue, o...

...nAllocatable registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !MRI->use_nodbg_empty(Reg) If the register is virtual, then MRI->use_nodbg_empty() returns false, if the register is physical LivePhysRegs[Reg] returns false, since the bitvector was inverted. So my instruction is considered dead and deleted. So, what I am tryin...

OK, details: I run RH8 (gcc 3.2.something), RH9 (gcc 3.2.2-5) and Fedora. Problems are the same across all setups. Hardware is Athlon 1600+ and half a giga RAM. Runs fail with an assertion when the linear scan allocator is enabled, but runs without problems otherwise. On RH9 (the system I have access to while generating this email) I have the following details: > 1) The LLVM assembly

...e registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: > > TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !MRI->use_nodbg_empty(Reg) > > If the register is virtual, then MRI->use_nodbg_empty() returns false, if the register is physical LivePhysRegs[Reg] returns false, since the bitvector was inverted. So my instruction is considered dead and deleted. > Huh...

...nAllocatable registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !MRI->use_nodbg_empty(Reg) If the register is virtual, then MRI->use_nodbg_empty() returns false, if the register is physical LivePhysRegs[Reg] returns false, since the bitvector was inverted. So my instruction is considered dead and deleted. Huh? The code is...

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units)) collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); } else { // Collect ranges for individual virtual registers....

On Wed, Apr 21, 2004 at 11:01:48AM +0200, Finn S Andersen wrote: > For some of the benchmarks the linear scan regalloc > works. When it does, results are in the x1.0 - 1.5 > range. Unfortunately, the linear scan allocator breaks > on most of my code. Is there a chance you can try cvs? I would be interested to get a simplified test case where the allocator breaks. A lot of

...g the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that there's a lot more ctors than consumers of MCRegister. It seemed cheaper to do the checks when they're consumed and pretty much every consumer I encountered started with `assert(Reg.isPhysicalRegister() && ...)`. > On 29 Sep 2020, at 11:02, Mircea Trofin <mtrofin at google.com> wrote: > > Thanks! To test my understanding - we could add asserts in MCRegister ctor that the value of the unsigned is, indeed, only in the physical register namespace, is that correct? > &...

...which is part of the SSA /// namespace. This must be the same for all targets, which means that each - /// target is limited to 1024 registers. - FirstVirtualRegister = 1024 + /// target is limited to this fixed number of registers. + FirstVirtualRegister = 16384 }; /// isPhysicalRegister - Return true if the specified register number is in On 12/09/2009 03:34 AM, Evan Cheng wrote: > On Dec 8, 2009, at 3:31 PM, Jakob Stoklund Olesen wrote: > >> On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: >> >>> This caused a massive slow down to post-ra scheduler...

...g the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that there's a lot more ctors than consumers of MCRegister. It seemed cheaper to do the checks when they're consumed and pretty much every consumer I encountered started with `assert(Reg.isPhysicalRegister() && ...)`. > > Not sure I follow - asserts are elided in release builds - or is there a different cost? Even though the release builds elide them there's still a cost to the compiler engineers using asserts builds for their daily development. >> On 29 Sep 2020, at 11:0...

On Dec 8, 2009, at 3:31 PM, Jakob Stoklund Olesen wrote: > > On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: > >> This caused a massive slow down to post-ra scheduler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding

...nAllocatable registers and assigns that to the LivePhysRegs for each basic block in a function. The function then loops through all instructions in a basic block and checks to see if it is a dead instruction. The check is whether it is a physical register or not with the check: TargetRegisterInfo::isPhysicalRegister(reg) ? LivePhysRegs[Reg] : !MRI->use_nodbg_empty(Reg) If the register is virtual, then MRI->use_nodbg_empty() returns false, if the register is physical LivePhysRegs[Reg] returns false, since the bitvector was inverted. So my instruction is considered dead and deleted. Huh? The code is...

...M, Arnold Schwaighofer <arnolds at codeaurora.org> wrote: > The code in collectRanges() does: > > // Collect ranges for register units. These live ranges are computed on > // demand, so just skip any that haven't been computed yet. > if (TargetRegisterInfo::isPhysicalRegister(Reg)) { > for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) > if (LiveInterval *LI = LIS.getCachedRegUnit(*Units)) > collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); > } else { > // Collect ranges for individual...

...MachineFunction::iterator EntryMBB = mf_->begin(); SmallVector<MachineBasicBlock*, 8> LiveInMBBs; for (LiveIntervals::iterator i = li_->begin(), e = li_->end(); i != e; ++i) { LiveInterval &cur = *i->second; unsigned Reg = 0; bool isPhys = TargetRegisterInfo::isPhysicalRegister(cur.reg); if (isPhys) Reg = cur.reg; else if (vrm_->isAssignedReg(cur.reg)) Reg = attemptTrivialCoalescing(cur, vrm_->getPhys(cur.reg)); if (!Reg) continue; // Ignore splited live intervals. if (!isPhys && vrm_->getPreSplitReg(cur.reg))...

...a new one. >> Eventually all Register instances are replaced by a MCRegister. >> >> What happens in that case to the stack slot APIs? Registers that are stack slots are never converted to MCRegister. That's not enforced in the constructor but it is enforced in MCRegister::isPhysicalRegister() >> Cheers, >> -Quentin >> >> > On Sep 28, 2020, at 5:46 PM, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> > >> > Hello, >> > >> > I'm trying to understand w...

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

...e attached bc to narrow down the bug. Thanks a lot for any help. ---------------------- The message I get when running the attached bc: [finna at coplin11 fft]$ lli -regalloc=linearscan a.out.bc lli: /home/finna/llvm/llvm/include/llvm/Target/MRegisterInfo.h:144: static bool llvm::MRegisterInfo::isPhysicalRegister(unsigned int): Assertion `Reg && "this is not a register!"' failed. lli[0x849e768] lli[0x849e974] /lib/tls/libc.so.6[0x420277b8] /lib/tls/libc.so.6(abort+0x1d5)[0x42028c55] /lib/tls/libc.so.6[0x42021043] lli(llvm::MRegisterInfo::isPhysicalRegister(unsigned)+0x25)[0x8314863]...

...[virtReg] && Virt2PhysMap[virtReg] != NO_PHYS_REG); 00190 } VRM::assignVirt2Phys is implemented as: 00147 void assignVirt2Phys(unsigned virtReg, unsigned physReg) { 00148 assert(TargetRegisterInfo::isVirtualRegister(virtReg) && 00149 TargetRegisterInfo::isPhysicalRegister(physReg)); 00150 assert(Virt2PhysMap[virtReg] == NO_PHYS_REG && 00151 "attempt to assign physical register to already mapped " 00152 "virtual register"); 00153 Virt2PhysMap[virtReg] = physReg; 00154 } Note that this doesn'...

...EBUG(dbgs() << " ComplexRemat MI: " << *DefMI); for (unsigned i = 0, e = DefMI->getNumOperands(); i != e; ++i) { const MachineOperand &MO = DefMI->getOperand(i); if (!MO.isReg() || !MO.getReg() || !MO.readsReg()) continue; if (TargetRegisterInfo::isPhysicalRegister(MO.getReg())) { if (MRI.isConstantPhysReg(MO.getReg(), *DefMI->getParent()->getParent())) continue; //If not constant then check its def if(depth > 6) return false; LiveInterval &li = LIS.getInterval(MO.getReg()); SlotIndex UseIdx = LIS....

Hi, I have a question about x86 code quality. I have run a few benchmarks and compared the running time of executables created by LLVM to executables created by gcc. It appears that code generated by LLVM is x1.5 - x3 times slower than code generated by gcc, for the x86 For some of the benchmarks the linear scan regalloc works. When it does, results are in the x1.0 - 1.5 range. Unfortunately,