search for: ragreedy

...aybe five hundred lines of library code. All times are in milliseconds, and the total includes both compilation and program execution. llvm-3.1: 2722 total 2342 llvm::ExecutionEngine::runFunctionAsMain 1144 SelectionDAGIsel::runOnMachineFunction 294 RegisterCoalescer::runOnMachineFunction 116 RAGreedy::runOnMachineFunction llvm-3.3: 53683 total 52661 llvm::ExecutionEngine::runFunctionAsMain 16955 RAGreedy::runOnMachineFunction 15149 RegisterCoalescer::runOnMachineFunction 15072 SelectionDAGIsel::runOnMachineFunction Both cases use createJIT with default values, so optimization is presumabl...

enableAdvancedRASplitCost() does the same thing as ConsiderLocalIntervalCost, but as a subtarget option instead of a command-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John From: Nirav Davé [mailto:niravd at google.com] Sent: 05 December 2018 17:14 To: John Brawn Cc: llvm-dev; nd Subject: Re: [llvm-dev] Strange re...

...plit in the same way that it is without 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...

...aybe five hundred lines of library code. All times are in milliseconds, and the total includes both compilation and program execution. llvm-3.1: 2722 total 2342 llvm::ExecutionEngine::runFunctionAsMain 1144 SelectionDAGIsel::runOnMachineFunction 294 RegisterCoalescer::runOnMachineFunction 116 RAGreedy::runOnMachineFunction llvm-3.3: 53683 total 52661 llvm::ExecutionEngine::runFunctionAsMain 16955 RAGreedy::runOnMachineFunction 15149 RegisterCoalescer::runOnMachineFunction 15072 SelectionDAGIsel::runOnMachineFunction Both cases use createJIT with default values, so optimization is presumabl...

...the spill option for a node, rather than spill immediately, split the interval first. This seems (superficially) like an opportunity to use trySplit, but I haven't looked at the code for it. If trySplit is looking at the existing allocation state to make those decisions we may have trouble: In RAGreedy some "current" colorings may be revisited, but during spilling in PBQP we're guaranteed that *all* colorings will be revisited in the next round, which may throw trySplit's heuristics out. 2) Pre-split -- We could have a pre-pass split live ranges at sensible points (e.g. around...

...ing rather than optimal coloring...". I would then think that any register allocation algorithm should benefit from this, but find that only RegAllocGreedy is doing live range splitting, and that the code for doing this is local to that allocator. I would like to suggest a refactoring to make RAGreedy::trySplit() and its sub functions callable from any register allocator. Perhaps part of SplitEditor? What do you think about this? /Jonas From: Arnaud A. de Grandmaison [mailto:arnaud.degrandmaison at arm.com] Sent: den 4 mars 2015 15:43 To: Jonas Paulsson; Lang Hames Cc: llvmdev at cs.uiuc.edu...

On Nov 16, 2011, at 10:23 AM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> You want LiveRangeEdit::allUsesAvailableAt() which performs the same >> check today. > > But not in 3.0, right? Yes, 3.0 defaults to RAGreedy which uses the new spilling framework. It is ignoring the -spiller=... command line option. Also note that SplitKit does cheap-as-a-copy rematerialization when splitting live ranges. Both go through LRE. Linear scan in 3.0 still uses the old stuff, that's why it wasn't deleted sooner. /...

...the spill option for a node, rather than spill immediately, split the interval first. This seems (superficially) like an opportunity to use trySplit, but I haven't looked at the code for it. If trySplit is looking at the existing allocation state to make those decisions we may have trouble: In RAGreedy some "current" colorings may be revisited, but during spilling in PBQP we're guaranteed that *all* colorings will be revisited in the next round, which may throw trySplit's heuristics out. trySplit splits either the given virtual register or some of its interference to make i...

...ally clear if you actually need that register to be reserved throughout the function, or if you just need it to be available around spill code. Both are possible, though. Note that this is a bit of a hack, since it won't work with the fast register allocator. You will need some custom code in RAGreedy since the current target APIs don't support this. When you spill, you can evict live ranges assigned to your 'reserved' register and put them back on the work queue. See for example the RAGreedy::LRE_WillShrinkVirtReg() callback. You can choose to evict all live ranges assigned to tha...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On Nov 16, 2011, at 9:15 AM, David Greene wrote: > >> I'm working on some enhancements to rematerialization that I hope to >> contribute. > > What do you have in mind? Rematting more types of loads. >> /// getReMatImplicitUse - If the remat definition MI has one (for now, we only >> /// allow one)

Jakob I've just noticed that I'm getting false positives about spills when there are actually none. What is happening is that although execution reaches to the line spiller().spill(LRE); inside RAGreedy::selectOrSplit() the insertion of the spill is avoided because the register gets rematted. This is the debug output I'm getting to show what I mean: Inline spilling DLDREGS:%vreg25,1.436782e-03 = [344r,640r:0) 0 at 344r >From original %vreg8,1.838235e-03 = [224r,640r:0) 0 at 224r Value %v...

...y help for a solution or a workaround will be greatly appreciated since this problem is severily limiting the complexity of the programs that I can currently compile. Those are some severe constraints on register allocation, but it ought to be possible anyway. You may wan't to investigate how RAGreedy::canEvictInterference() is behaving. /jakob

Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not having this register available. I find very interesting

...orms is identity copy elimination. It depends on the register allocator having split live ranges before spilling, so it doesn't try to undo anything like VirtRegRewriter does. StandardSpiller supported basic per-block live range splitting. Similar functionality using SplitKit can be found in RAGreedy::tryBlockSplit(). /jakob

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

...t->MergeSegmentsInAsValue(LIS.getInterval(RegsToSpill[i]), > StackInt->getValNumInfo(0)); > DEBUG(dbgs() << "Merged spilled regs: " << *StackInt << '\n'); > > And this is called by the register allocator in RAGreedy::selectOrSplitImpl. > > When the InlineSpiller calls LSS.getOrCreateInterval, that is a call to LiveStacks::getOrCreateInterval, and that updates the S2IMap inside of LiveStacks. > > -Hal > > > Furthermore, the LiveInterval analysis only computes live intervals > > for v...

Hello Jakob, > Those are some severe constraints on register allocation, but it ought to > be possible anyway. > Indeed, these constraints aren't playing very well with the register allocator :\ > > You may wan't to investigate how RAGreedy::canEvictInterference() is > behaving. > Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc fails with the following sequence: 1) directly assign the physreg in PTR RC to a virtX. 2) for a virtY which also belongs to the PTR RC, try to evict: call canEvictInt...

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been

...600% for some opcodes). To me this looks like the register allocator is too eager to load values which are only used by anyregcc patchpoints into registers, or is this the intended behavior of anyregcc patchpoints? I would be grateful for suggestions of how I could modify the register allocator (RAGreedy) to avoid reloading values when they are only used by instructions which are anyregcc patchpoints. During the last two weeks I have made a couple unsuccessful attempts at that and could really use some pointers from someone who understands it. Attached is a the smallest example I have managed to f...

Hi all, I've come across a problem with register allocation which I have been unable to track down the root cause of. 6728B %vreg304<def> = COPY %vreg278; VRF128:%vreg304,%vreg278 6736B %vreg302<def> = COPY %vreg278; VRF128:%vreg302,%vreg278 6752B %vreg278<def,tied1> = foo %vreg278<tied0>, %vreg277, 14, pred:1, pred:%noreg, 5; VRF128:%vreg278 VRF64_l:%vreg277 * bar