search for: virtregrewrite

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

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtReg...

Yes, I'm saying that the implicit-def operand that was added in this case ended up as #4, out of 6, when the operands list was reallocated in addOperand(). If addOperand was rewritten, I think it's best not to add my fix for ProcessUses(), as I wrote earlier. Jonas Subject: Re: [LLVMdev] VirtRegRewriter.cpp: LocalRewriter::ProcessUses() From: stoklund at 2pi.dk Date: Wed, 12 Oct 2011 09:14:52 -0700 CC: llvmdev at cs.uiuc.edu To: jnspaulsson at hotmail.com On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote:Hi, I think I've found a bug in this method. I ran it on an MI which already had two...

...spiller's class? RALinearScan asks the Spiller to spill a virtual register. The StandardSpiller passes the request to LiveIntervals::addIntervalsForSpills. Here, the spill and restore points are added to the VirtRegMap. No spill code has been inserted yet. After register allocation completes, VirtRegRewriter inserts the store and load instructions specified in VirtRegMap. The counters you are looking for are in VirtRegRewriter.cpp. We are working on simplifying this for obvious reasons. If you specify -spiller=inline, the InlineSpiller will insert loads and stores immediately. There are currently n...

Hi, Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug in this method. > > I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > >

Hi, I think I've found a bug in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg,

...t; RALinearScan asks the Spiller to spill a virtual register. The > StandardSpiller passes the request to LiveIntervals::addIntervalsForSpills. > Here, the spill and restore points are added to the VirtRegMap. No spill > code has been inserted yet. After register allocation completes, > VirtRegRewriter inserts the store and load instructions specified in > VirtRegMap. > > The counters you are looking for are in VirtRegRewriter.cpp. > I compiled "sort.c" from coreutils8.5 using both *local* and *linearscan* allocators (I'm using LLVM 2.7). For *local*, I get a Load/Stor...

Hi Susan, I'm having trouble reproducing that error on my end, but I think the problem is probably that you're not using the VirtRegRewriter infrastructure. What your allocator needs to do is populate the virtual register mapping (VirtRegMap pass) with your allocation, rather than rewriting the registers directly through MachineRegisterInfo. Have your allocator require and preserve the VirtRegMap pass, then in your runOnMachineFunctio...

Thanks Lang! Here's another question: I'm trying to process this input: int main() { return 0; } but I'm getting an error Assertion `!Fn.getRegInfo().getNumVirtRegs() && "Regalloc must assign all vregs"' failed. At the start of runOnMachineFunction I call Fn.getRegInfo().getNumVirtRegs(); and find that there is 1 virtual register. However,

...d to copy that file from the source directory. That seems suspicious. Any thoughts? Thanks! Susan On 10/31/2012 07:51 PM, Lang Hames wrote: > Hi Susan, > > I'm having trouble reproducing that error on my end, but I think the > problem is probably that you're not using the VirtRegRewriter > infrastructure. What your allocator needs to do is populate the virtual > register mapping (VirtRegMap pass) with your allocation, rather than > rewriting the registers directly through MachineRegisterInfo. > > Have your allocator require and preserve the VirtRegMap pass, then in...

The new spilling framework inserts spill code in-place (during register allocation) rather than deferring it using VirtRegMap/VirtRegRewriter. The goal is to enable techniques like iterative splitting to be implemented. It should also be a bit tidier as it keeps more state in the MachineFunction, rather than in book-keeping structures like VirtRegMap. The work is in the very early stages though. - Lang. On Thu, Jun 4, 2009 at 1:46 PM,...

...gt; is gone. There is a good chance it won't make it to the 3.0 release. > > Believe me, I understand the desire to clean this code up. What's > particular about linearscan in this regard? What parts are hard to > clean up due to linearscan? The new allocator doesn't use VirtRegRewriter. Deleting that alone will improve the average code quality significantly. The worst parts of LiveIntervalAnalysis.cpp can also be deleted. Once all that code is gone, it is much easier to refactor the LiveIntervals interface. /jakob

On Thursday 04 June 2009 13:57, Lang Hames wrote: > R.I.P. SimpleRewriter. If anyone needs it resurrected let me know. > > This leaves LocalRewriter (the default) and the new TrivialRewriter, > which is for use only with the new in-place spilling framework. This > framework appears (if you squint just right) to be basically > functional now, but it produces awful code. If you

...> I see. > > Unfortunately, this is causing some customer code to fail in compilation. The direct cause of the compilation failure is a complaint from the register scavenger in the scenario that I described in the first email. It shouldn't be causing any compile time failures, the VirtRegRewriter is adding <imp-def> operands for the wide register to make it look like it is live everywhere the virtual register was live: vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register Should be rewritten as: physreg(32) = other-physreg(32), physreg(64)<imp-def> In the worst case...

...e to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. I have tried two techniques, in the MachineFunction: 1. replace the MachineOperands in the users of the data with the new register/subregister index. This yields an assert failure during VirtRegRewriter, in substPhysReg: "Invalid SubReg for physical register", after the Two-address rewrote this: %reg16445<def> = add %reg16507:hi16, %reg16510:hi16 ; 32bit:16507,16510, 16bit: 16445 prepend: %reg16445<def> = COPY %reg16507; rewrite to: %reg16445<def> = addh_...

...uspicious. > > Any thoughts? > > Thanks! > > Susan > > > On 10/31/2012 07:51 PM, Lang Hames wrote: > >> Hi Susan, >> >> I'm having trouble reproducing that error on my end, but I think the >> problem is probably that you're not using the VirtRegRewriter >> infrastructure. What your allocator needs to do is populate the virtual >> register mapping (VirtRegMap pass) with your allocation, rather than >> rewriting the registers directly through MachineRegisterInfo. >> >> Have your allocator require and preserve the VirtR...

On 1/14/2013 3:16 PM, Jakob Stoklund Olesen wrote: > > On Jan 14, 2013, at 12:56 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> My question is: is this something that was a part of the design? > > Yes, the register allocator only deals in full-width virtual registers, so any copies or spills created will operate on the full register. I see.

...simpdefs -unreachable-mbb-elimination -livevars -machinedomtree -machine-loops -phi-node-elimination -twoaddressinstruction -slotindexes -liveintervals -simple-register-coalescing -misched -machine-block-freq -livedebugvars -livestacks -virtregmap -liveregmatrix -edge-bundles -spill-code-placement -virtregrewriter -stack-slot-coloring -machinelicm -edge-bundles -prologepilog -machine-block-freq -branch-folder -tailduplication -machine-cp -postrapseudos -machinedomtree -machine-loops -post-RA-sched -gc-analysis -machine-block-freq -block-placement2 -stackmap-liveness Thanks, Trent -------------- next part -...

...ctions: PHIs are values that are defined by control > > flow. To deal with this pre-regalloc, we could move LiveDebugVariables > > to run before phi-elimination. > > I don’t really follow this. Are you suggesting stripping out debug values before phi elim, and replacing them after virtregrewrite? How would the re-inserted debug instrs refer to values produced by phis? > > > My understanding is that the register > > allocation phase of LLVM starts there and ends after virtregrewriter, > > and it'd be legitimate to say "we do special things for these passes&quot...