Displaying 20 results from an estimated 28 matches for "unspilling".
Did you mean:
spilling
2014 Jul 08
1
[PATCH] nv50/ir: use unordered_set instead of list to keep our instructions in uses
This shortens runtime of piglit test fp-long-alu to ~22s
No piglit regressions observed on nvc0!
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp | 6 +++---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 7 ++++---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-
2008 May 09
2
[LLVMdev] Complicated Remat Question
Ok, this is a rather complicated e-mail. Please ask questions if you don't
understand something.
I've come across an interesting problem. I'm merging our graph coloring
allocator with the code from trunk as of late last week. I have a code where
a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is
spilled and at least one use is rematted. The remat def
2014 Feb 14
0
Regression caused by 2e9ee44797 ("nv50/ir/ra: some register spilling fixes")
Hi Christoph,
bin/shader_runner
tests/spec/glsl-1.40/uniform_buffer/fs-struct-copy-complicated.shader_test
-auto
bin/shader_runner
tests/spec/glsl-1.40/uniform_buffer/vs-struct-copy-complicated.shader_test
-auto
bin/shader_runner
tests/spec/glsl-1.50/uniform_buffer/gs-struct-copy-complicated.shader_test
-auto
Now all segfault. I reverted 2e9ee44797 ("nv50/ir/ra: some register
spilling
2006 Aug 06
2
[LLVMdev] Recalculating live intervals
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:
2006 Aug 06
0
[LLVMdev] Recalculating live intervals
On Sun, 6 Aug 2006, Anton Vayvod wrote:
> 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.
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
2013 Jan 09
0
[LLVMdev] LLVM ERROR: ran out of registers during register allocation
On Jan 9, 2013, at 10:46 AM, Borja Ferrer <borja.ferav at gmail.com> wrote:
> 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
2006 Aug 21
3
[LLVMdev] Recalculating live intervals
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
2015 Sep 01
2
Spilling Virtual Registers
Hello to all LLVM developers.
I'm developing a register allocator using LLVM, my allocator has a local
search phase: given a solution (assignment of virtual registers to physical
registers or memory) generated in the first phase of the algorithm, some
movements are applied to this solution in order to find a better solution.
To apply such movements, I need to unassign a virtual register from
2015 Nov 02
2
How to prevent registers from spilling?
That breaks the whole IR idea of using 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
2010 Aug 31
0
[LLVMdev] "Ran out of registers during register allocation" bug affecting ffmpeg
On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote:
> 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
2013 Jan 09
2
[LLVMdev] LLVM ERROR: ran out of registers during register allocation
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
2012 Mar 21
2
[LLVMdev] PBQP & CalcSpillWeights
Hi All,
I finally had a chance to get back to my pbqp trials, now using the 3.0
release. I still hit the same assert : "Attempting to spill already spilled
value."
This is triggered because in RegAllocPBQP::mapPBQPToRegAlloc, a vreg node is
either :
- a physical register (problem.isPRegOption(vreg, alloc)),
- or a spill (problem.isSpillOption(vreg, alloc))
The problem is that pass
2010 Aug 22
2
[LLVMdev] "Ran out of registers during register allocation" bug affecting ffmpeg
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]
2016 May 28
7
[Bug 96258] New: [NVC0] Hang when running compute program
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
2016 Feb 06
2
gc relocations on exception path w/RS4GC currently broken
Thanks, I think that's a useful way to look at it (though if I wanted to bikeshed I'd suggest the name "DoubleIndirect" as a bit more precise than "VeryIndirect").
An aspect of it that I'm still puzzling over is that my target runtime (at least in its current form) doesn't have a way to represent/process a "VeryIndirect" pointer. So I'd like to
2013 Oct 21
1
[LLVMdev] [PATCH] Unwanted r11 in push/pop on Cortex-M.
To recap, this is what I was trying to solve:
This C code:
int bar(int a, int b, int c, int d, int e, int f);
int foo(int a, int b, int c, int d, int e )
{
int x = 3*a;
return bar3(a,b,c,d,e,x);
}
Produced the following assembly output:
foo:
push {r11, lr}
sub sp, #8
bl bar
add sp, #8
pop {r11, pc}
The part I didn't like is that push/pop become
2016 Feb 05
2
gc relocations on exception path w/RS4GC currently broken
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
2006 Aug 21
2
[LLVMdev] Recalculating live intervals
On 8/7/06, Chris Lattner <sabre at nondot.org> wrote:
>
> On Sun, 6 Aug 2006, Anton Vayvod wrote:
> > 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.
>
> Take a look at the linear scan allocator. It is also iterative: it uses
>
2015 May 06
4
[Bug 90348] New: Spilling failure of b96 merged value
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
2018 Dec 05
2
Strange regalloc behaviour: one more available register causes much worse allocation
Preamble
--------
While working on an IR-level optimisation completely unrelated to register
allocation I happened to trigger some really strange register allocator
behaviour causing a large regression in bzip2 in spec2006. I've been trying
to fix that regression before getting the optimisation patch committed, because
I don't want to regress spec2006, but I'm basically fumbling in