search for: splitkit

...ize down the heuristics don't cope well. Currently the PBQP allocator does not do any splitting, however I expect that it should be easy to add support for on-demand splitting, and I'll be looking into it soon-ish. I haven't had time to work on the LoopSplitter recently. It looks like SplitKit has subsumed LoopSplitter's functionality. If that's the case then I can go ahead and kill off LoopSplitter. Cheers, Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100921/add0835d/attachment.h...

...hird best hint, etc as well. > Currently the PBQP allocator does not do any splitting, however I expect that it should be easy to add support for on-demand splitting, and I'll be looking into it soon-ish. > > I haven't had time to work on the LoopSplitter recently. It looks like SplitKit has subsumed LoopSplitter's functionality. If that's the case then I can go ahead and kill off LoopSplitter. SplitKit is currently pretty broken, but I am working on fixing it. It turns out you need a good deal of logic to correctly update LiveIntervals after a split. The intention is that...

I looked at SplitKit, but I am not sure how to best do it, so it would be great if you could take a look. /Jonas On 2015-04-21 19:35, Quentin Colombet wrote: >> On Apr 21, 2015, at 7:40 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> >>> On Apr 21, 2015, at 05:39, Jonas...

...Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com <mailto:jonas.paulsson at ericsson.com>> wrote: >> >> I looked at SplitKit, but I am not sure how to best do it, so it would be great if you could take a look. > > Sure. > I will try to do that by the end of the week. > > Cheers, > Q. > >> >> /Jonas >> >> >> On 2015-04-21 19:35, Quentin Colombet wrote: >>>&...

...same def, in the sense that they can be traced through copies, phis, etc. back to a single instruction? I'm looking at scheduling the load in my example and I need to be able to check for conflicting stores within relevant live ranges. Is there a design document for the new InlineSpiller and SplitKit somewhere? -Dave

...only optimization it performs 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

On Sep 20, 2010, at 7:53 AM, Lang Hames wrote: > I've just committed some changes to the PBQP allocator which are designed to make it easier to implement custom register allocation constraints. This is a quick summary of those changes, and of the status of the PBQP allocator in general. Thanks, Lang! Out of curiosity, how are you dealing with live range splitting and coalescing in PBQP?

...lund 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. /jakob

On Sep 19, 2012, at 10:49 AM, <dag at cray.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > > So if there are multiple values between r2 and r3 (r2.1, r2.2, etc.) I > would just follow the chains implied by the SibValueInfo Deps array? > Basically, I want to find all of the live ranges related to r1. It really depends on what you're trying to do.

...are known the all come from the same value in the original live range from before live range splitting. The defining instruction may not exists any longer. It could have been rematerialized somewhere else. It could also have been PHI. > Is there a design document for the new InlineSpiller and SplitKit > somewhere? No. /jakob

> On Apr 21, 2015, at 05:39, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Could it then be that the RegisterCoalescer should split live ranges when LIS->shrinkToUses() return true? Why does it not do that, when the verifier demands this? I think it should. That's an oversight.

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> If we decide to spill r3, we call traceSiblingValue to find the original >> def (the load). After traceSiblingValue we have the load instruction to >> define r1 and the value number information for r3. We don't have the >> value information from r2 as far as I can tell. >> >> Is that correct?

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)

Hi Jakob, Thanks for a very interesting description of the new register allocation algorithm in LLVM!!! Could you elaborate a bit on the following topics: 1) Do you have any plans to publish something more formal and detailed about this algorithm, e.g. a paper or something similar?  It would be nice to better understand how this algorithm relates to well-known algorithms described in the

...assertion (shown below) that is fired when I run llc with -march=mipsel -mcpu=4ke. It seems to me that the root cause of this assertion is the piece of code shown above that is called during PHI nodes elimination (llc exits normally if I add -disable-phi-elim-edge-splitting). llc: llvm/lib/CodeGen/SplitKit.cpp:170: bool llvm::SplitAnalysis::calcLiveBlockInfo(): Assertion `BI.FirstUse >= Start' failed. The following is the Machine IR and LiveVariables::ValInfo dump before and after PHI nodes elimination. 1. Before PHI nodes elimination. -Machine IR: BB#14: derived from LLVM BB %for.cond151.p...

I just uploaded a blog post outlining the new register allocation algorithm in LLVM 3.0. http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html Please direct comments here. /jakob

On Mon, Aug 30, 2010 at 5:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > 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

Hi All, I've just committed some changes to the PBQP allocator which are designed to make it easier to implement custom register allocation constraints. This is a quick summary of those changes, and of the status of the PBQP allocator in general. First a quick bit of background: The PBQP allocator is based on ideas described in [1]. I implemented this algorithm (with the improved heuristic

...ng.cpp for Release+Asserts build llvm[2]: Compiling ShrinkWrap.cpp for Release+Asserts build llvm[2]: Compiling SjLjEHPrepare.cpp for Release+Asserts build llvm[2]: Compiling SlotIndexes.cpp for Release+Asserts build llvm[2]: Compiling SpillPlacement.cpp for Release+Asserts build llvm[2]: Compiling SplitKit.cpp for Release+Asserts build llvm[2]: Compiling StackColoring.cpp for Release+Asserts build llvm[2]: Compiling StackMapLivenessAnalysis.cpp for Release+Asserts build llvm[2]: Compiling StackMaps.cpp for Release+Asserts build llvm[2]: Compiling StackProtector.cpp for Release+Asserts build llvm[2]:...