search for: unspill

...egin())->getInsn(); // if this is a contraint-move there will only be a single use if (i && i->op == OP_MERGE) // do we really still need this ? break; @@ -1559,7 +1559,7 @@ SpillCodeInserter::run(const std::list<ValuePair>& lst) // Unspill at each use *before* inserting spill instructions, // we don't want to have the spill instructions in the use list here. while (!dval->uses.empty()) { - ValueRef *u = dval->uses.front(); + ValueRef *u = *dval->uses.begin(); Instruc...

...ReMatDefs. %reg1461 is created for one of the spill intervals of %reg1235. It is marked as rematerializable with defining instruction: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 8, Mem:LD(8,8) [tmp17641765 + 0] Note that this is the same instruction as above. %reg1097 is marked unspillable (weight set to HUGE_VALF). %reg1461 gets assigned XMM15 by the register allocator. Later on %reg1364 is spilled and assigned a stack slot. When rewriting instructions after regalloc, we come across this instruction: %XMM3<def> = MOVSDrr %reg1461, %R12<imp-use> %reg1461 was mark...

...on NVC0+, so it'd be nice to get everything working together all at once :) Below is a backtrace... looks like slot == NULL. Let me know if you need anything else from me. Thanks, -ilia Program received signal SIGSEGV, Segmentation fault. 0x00007ffff2756598 in nv50_ir::SpillCodeInserter::unspill ( this=0x7fffffffd160, usei=0x76a9a0, lval=0xc08f30, slot=0x0) at codegen/nv50_ir_ra.cpp:1514 1514 if (slot->reg.file == FILE_MEMORY_LOCAL) { (gdb) bt #0 0x00007ffff2756598 in nv50_ir::SpillCodeInserter::unspill ( this=0x7fffffffd160, usei=0x76a9a0, lval=0xc08f30, slot=0x0)...

Hi! I'm developing a register allocator that works iteratively. It spills some virtual registers on each iteration until all the rest have physical ones assigned. How can I spill some live intervals at the end of each iteration with new live intervals having correct weights? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...developing a register allocator that works iteratively. It spills some > virtual registers on each iteration until all the rest have physical ones > assigned. Take a look at the linear scan allocator. It is also iterative: it uses the spiller interface to insert spill code, which creates (unspillable) intervals for the spill code it inserts. > How can I spill some live intervals at the end of each iteration with new > live intervals having correct weights? The linscan allocator inserts spill code with infinite weight, take a look at how it works. -Chris -- http://nondot.org/sab...

...ing this for all live intervals of this regclass, I'm filtering only the ones that dont have a small size (returned by li.getSize()) > > Does this possible cause make any sense at all? Yes, that sounds like a workable fix. It is important that live ranges coming out of the spiller are unspillable, but the zero length intervals don't need an infinite spill weight - very very large is good enough. > In either case, in the meantime, I can live with this workaround until an official fix is implemented. I'll fill in a bug report to track this problem so you can take a look at it...

I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills

...to unassign a virtual register from a physical register and one from the memory, and swap those two. To unassign from a physical register, the method *unassign* from the *LiveRegMatrix* class can be used. But, in the other hand, the class *InlineSpiller* doesn't provide a similar method, like *unspill*. So I thought, instead of applying the spill directly during the first phase of the algorithm, I would store the virtual registers candidates to spill in an auxiliary structure. So that when it was decided to apply spill at some virtual register, it would be added to the structure and that would...

...sing alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you cannot know whether the callee may save that or not. And if it is in a caller-save register, then the caller has to spill it if it is live across a call. Kevin B. Smith -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at list...

...hysreg with a virtreg that is live across the inline asm. This is not easy to detect without a bad compile time regression. I suppose something similar could happen for calls. For instance, some calls clobber all XMM registers, so a physical XMM register coalesced to be live across a call would be unspillable. What can I say? Physreg coalescing is evil ;-) I want to remove physreg coalescing entirely, but it requires the register allocator to be really good at taking hints. We are not quite there yet. A quick fix would be to disable physreg coalescing for functions containing inline asm. /jakob

Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code

...gister (problem.isPRegOption(vreg, alloc)), - or a spill (problem.isSpillOption(vreg, alloc)) The problem is that pass CalcSpillWeights can 'hint' that it is a poor idea to spill this specific register with : CalcSpillWeights.cpp / VirtRegAuxInfo::CalculateWeightAndHint : // Mark li as unspillable if all live ranges are tiny. if (li.isZeroLength(LIS.getSlotIndexes())) { li.markNotSpillable(); ... This hint makes the register non spillable at all for the spiller (that's the assert above), not just a bad-idea-to-spill-but-feasible. The pbqp allocator does not cope with thi...

See http://llvm.org/bugs/show_bug.cgi?id=4668 and http://llvm.org/bugs/show_bug.cgi?id=5010. The basic description of the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The fundamental problem is we can't spill a register once it's fixed to a physical register." >From discussion on IRC: [17:14] <_sabre_> efriedma: sounds like a RA bug in linscan [17:14]

https://bugs.freedesktop.org/show_bug.cgi?id=96258 Bug ID: 96258 Summary: [NVC0] Hang when running compute program Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

...he reference is *(Reg+Offset) VeryIndirect == the reference is **(Reg+Offset) (This following bit is re-iterating what Joseph and I talked about on Skype, so that everyone is up to speed) gc.statepoint would then have two different "argument regions" for reporting heap references, "unspilled" and "spilled". Lowering for the "unspilled" region would what we currently have for GC references. Lowering for the "spilled" region would be: emit code normally (i.e. what we do today), but if you were going to report the location as Direct, then report it a...

...avedScan - at this point the we need to fix the fact that SP would not be EABI compliant because only 1 register has been spilled so far - inside processFunctionBeforeCalleeSavedScan, there a check: if TargetAlign == 8 && (NumGPRSpills & 1) then we align the stack by pushing one of the _unspilled_ registers. The problem is that this "unspilled" register list starts with r11 (for reasons I'm not clear about), so I decided to skip all the registers r8-r15. The part I'm not sure about is: what if r4-r7 are all spilled already, is the SP going to be aligned by some other ro...

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like

...that works iteratively. It spills > some > > virtual registers on each iteration until all the rest have physical > ones > > assigned. > > Take a look at the linear scan allocator. It is also iterative: it uses > the spiller interface to insert spill code, which creates (unspillable) > intervals for the spill code it inserts. > > > How can I spill some live intervals at the end of each iteration with > new > > live intervals having correct weights? > > The linscan allocator inserts spill code with infinite weight, take a look > at how it works...

https://bugs.freedesktop.org/show_bug.cgi?id=90348 Bug ID: 90348 Summary: Spilling failure of b96 merged value Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

...t the patch, which I think means deciding that there's only 1 bundle for w15. Does anyone know where and how exactly these bundles are decided? * Try and change how evicted / split registers are allocated in some way. Things I've tried: * In RAGreedy::enqueue reduce the score of unspillable local intervals, and in RAGreedy::evictInterference put evicted registers into stage RS_Split immediately. This causes %381 to be split immediately instead of being requeued, and then makes %391 have a higher score than %253 causing it to be allocated before it. This works, but...