search for: r2rmap

...operties (i.e., > they don't require an interference graph). I'm definitely interested in improving coalescing and it sounds like this would fall under that work. Do you have references to papers that talk about the various algorithms? > Beyond that, one of the issues is the "r2rmap" and "rep" function. As > you've noticed, the coallescer basically uses these to avoid rewriting the > code after it does coallescing. For example, if r1024 is coallesced with > r1026, it leaves all uses of both registers in the code, instead of > rewriting uses...

...nce properties (i.e., they don't require an interference graph). > So far, this has been pretty easy. I've created a new > SimpleRegisterCoalescing pass and the member functions > divide pretty cleanly between than and LiveIntervals. Beyond that, one of the issues is the "r2rmap" and "rep" function. As you've noticed, the coallescer basically uses these to avoid rewriting the code after it does coallescing. For example, if r1024 is coallesced with r1026, it leaves all uses of both registers in the code, instead of rewriting uses of r1026 with r1024...

...2:37 PM, David Greene wrote: > Chris Lattner wrote: >> On Thu, 12 Apr 2007, David Greene wrote: >>> As I work toward improving LLVM register allocation, I've >>> come across the need to do some refactoring. Yay! >> Beyond that, one of the issues is the "r2rmap" and "rep" >> function. As >> you've noticed, the coallescer basically uses these to avoid >> rewriting the >> code after it does coallescing. For example, if r1024 is >> coallesced with >> r1026, it leaves all uses of both registers in...

...current code needs a lot of massaging. If you are > interested (after your first rounds of refactoring), please consider > a replacement for LiveInterval that keeps more accurate info that can > be plugged into the same existing allocator. The next step is to do > away with the r2rmap and rep(). This gets back to my questions about what LiveIntervals lacks. - What "data structure" are you referring to above? - What specific def-use info is needed that we don't have access to currently? - A couple of weeks ago I asked about the comment in LiveIntervalAnaly...

...hat's a project for later. Doing this would increase compile time slightly as it would require an extra pass over the program. Is this ok? The problem is LiveIntervals::CreateNewLiveInterval. This member references LiveIntervals::rep, which as far as I can tell makes use of temporary state (r2rMap_) generated during the coalescing pass. My reading indicates that at final loop nest of LiveIntervals::runOnMachineFunction replaces operand registers with using rep() which makes use of r2rMap_. So why does LiveIntervals::CreateNewLiveInterval use r2rMap_? Actually, in the official sources, this...

On Thu, 12 Apr 2007, David Greene wrote: >> Beyond that, one of the issues is the "r2rmap" and "rep" function. As >> you've noticed, the coallescer basically uses these to avoid rewriting the >> code after it does coallescing. For example, if r1024 is coallesced with >> r1026, it leaves all uses of both registers in the code, instead of >> re...

.... The point is, the current code needs a lot of massaging. If you are interested (after your first rounds of refactoring), please consider a replacement for LiveInterval that keeps more accurate info that can be plugged into the same existing allocator. The next step is to do away with the r2rmap and rep(). Thanks, Evan > >> These are things I will definitely have to do here so I'm quite >> interested in how this will all work. I'm more than happy to do >> a bunch of heavy lifting getting things into shape. > > Great! > > -Chris > > -- &gt...

...code needs a lot of massaging. If you are >> interested (after your first rounds of refactoring), please consider >> a replacement for LiveInterval that keeps more accurate info that can >> be plugged into the same existing allocator. The next step is to do >> away with the r2rmap and rep(). > > This gets back to my questions about what LiveIntervals lacks. > > - What "data structure" are you referring to above? LiveInterval, LiveRange, and friends. > > - What specific def-use info is needed that we don't have access > to currently? Q...

On Tue, 17 Apr 2007, David Greene wrote: > Evan Cheng wrote: >> Obviously, smart heuristics can make a big difference here (estimated >> register pressures, etc.) But the more important thing is how the >> passes down stream can recover from the earlier mistakes. By this, we >> mean live range splitting and re-materialization. > > Can you explain this a little

...the current code needs a lot of massaging. If you are > interested (after your first rounds of refactoring), please consider > a replacement for LiveInterval that keeps more accurate info that can > be plugged into the same existing allocator. The next step is to do > away with the r2rmap and rep(). While implementing Wimmer's linear scan, which is heavily based on splitting of live intervals, I already extended LiveInterval to contain more detailed info about all def-use occurrences. I also implemented the functionality for splitting a live interval at any place. Additionally,...