search for: coallescing

...ds as the same bug. Two questions: 1) At least, it would be better if LLVM would crash on an assertion instead of running for ever in such situations. I think this can be easily detected, since this is a case where nothing could be spilled. 2) You write in PR711: >This is due to the coallescer coallescing virtregs with both EAX and >EDX, which makes them unavailable to satisfy spills, causing the RA to >run out of registers. We want to coallesce physregs when possible, >but we cannot pin them in the spiller: >we have to be able to >uncoallesce them. First of all, I totally agree...

...locators might > like to do coalescing differently (e.g. graph coloring does it by > examining the interference graph). It would also allow different > heuristics and coalescing strategies. Ok. Another thing to ponder on: Our current phi elimination pass is the source of many of our coallescing-related issues. Currently, each phi is lowered into one copy for the result and one copy for each input. This is a *lot of copies*! This is a problem both for coallescing (because it has to do so much, it is required to be very aggressive) and compile time (phi elim + coallescing is much slo...

...ange splitting, register allocation and spilling? > > This is one of the reasons I want to separate all of these concerns. > We shouldn't force developers to always coalesce or always use some > generic measure of spill cost. In my mind (a dangerous place to go), it's not about coallescing vs spilling, it's about splitting vs spilling. In particular, coallescing does increase live ranges of values, but you can have the same increase from code written without copies. Basically, not doing aggressive copy coallescing means that you are dependent on the user telling you where l...

Chris Lattner wrote: >> Doesn't that last statement actually do the rewrite? > > Hrm, yes, yes it appears so. Question is: doesn't this make the r2r map > dead? Does something else fill it in? My memory is hazy here :). If it > is dead, we should rip it out (actually, we should make it private to the > coallescer function). I'm trying an experiment to

...l 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 of r1026 with r1024 and deleting all memory of r1026. This > mades sense long ago, but now it is increasingly clear that this is a bad > idea. I would m...

On Mon, 16 Apr 2007, David Greene wrote: > Chris Lattner wrote: >>> Doesn't that last statement actually do the rewrite? >> Hrm, yes, yes it appears so. Question is: doesn't this make the r2r map >> dead? Does something else fill it in? My memory is hazy here :). If it >> is dead, we should rip it out (actually, we should make it private to the >>

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 >> rewriting uses of r1026 with r1024 and deleting all memory of r1026. This >> mades sense long ago, but now it is increasingly clear that this is a bad >> idea...

Hi all, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

Chris Lattner wrote: > No there isn't, unfortunately. I'd suggest building up/maintaining the > r2r map inside the coallescer. Once the coallescer is done with the > entire function, do a single pass over the function rewriting all the > coallesced vregs. Ok. I have a version with the coalescer separated from liveIntervalAnalysis. It still uses the r2r map but as we

Here''s a peculiar one. I''m trying to simulate some speed effects due to varying sized packets so I have written a quick perl app which spits out packets of a fixed size (<1500 bytes). What I''m finding is the despite apparently turning off nagle and everything else I can think of I still notice that when the receiver isn''t keeping up that the sending

...;>> 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 the code, instead of >> rewriting uses of r1026 with r1024 and deleting all memory of >> r1026. This >> mades sense long ago, but now it is increasingly clear that this...

On Fri, 30 Jun 2006, Fernando Magno Quintao Pereira wrote: > where %reg1032 is dead. Right. One of the jobs of the register allocator is to coallesce register copies. Once coallesced, they can be removed. > I'm removing these instructions. In Linear scan, they are removed too. > I'm removing all the dead definitions from instructions that are not > function calls, and

Chris Lattner wrote: > On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >>> 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? >> Some suggestions: >> >> @InProceedings{Budimlic02, >> AUTHOR =

On Thu, 12 Apr 2007, Fernando Magno Quintao Pereira wrote: >> 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? > > Some suggestions: > > @InProceedings{Budimlic02, > AUTHOR = {Zoran Budimlic and Keith D. Cooper and Timothy

On Thu, 21 Dec 2006, Roman Levenstein wrote: > following: > 1) some of the fixed registers intervals are merged with some virtual > registers intervals > 2) later there is a need to spill one of the allocated registers, but > since all joined intervals are FIXED intervals now due to (1), they > cannot be spilled. Therefore, the register allocator loops for ever. > > I would

> > It seems to me that the only instructions > > with dead definitions that I should not remove are the calls. Is it true? > > I would like to know if a code like this below is safe, that is, besides > > call instructions, is there other instructions that must stay in the code > > even if their definitions are dead? > > > > MachineInstr * mi = iter; >

...known<"if <>0 goto">; ..... Should this work? > Also, if you haven't already, you might want to teach TargetInstrInfo > that '=' is a move instruction (implement isMoveInstr), so instructinos > like 'gr1 = gr1' will go away and you'll get coallescing. :) BTW, is it possible to set some instruction flag, instead of overriding a function? Something like: let isMove = 1 in def MOVE :..... ? - Volodya

> > Why it is named RETFLAG? > > Historical reason. Originally we didn't have nodes that could > *optionally* have an input flag. A better design, e.g. on PPC would be to > have a PPCISD::RET node, which takes an optional input flag, and always > lower RET to it. I See. I will try to always lower to "(mov)*;bx lr" on ARM. > Flag in the SelectionDAG stuff is

...ction). Right. You don't want to do this sort of partitioning. All of the 'computed' values should be virtual registers which will end up being assigned to GPRs. The register allocator will attempt to coallesce the GPR into an output or input register if possible. To allow this coallescing to happen, implement the TargetInstrInfo::isMoveInstr virtual method for your target. > The same problem exists when there are two types of costant registers, > floating point and integer, and each is declared 'packed' ([4xfloat] > and [4xint]). The instruction selector doesn'...

...l register if we ever joined > an interval of a real register with one of a virtual register (and this > real register will be the representative register of the set of > intervals joined together). I understand the representative register could be a physical (real) register if one of the coallescing register is a physical register. But the code _uncondtionally_ changes MachineOperand::optype to MO_MachineRegister, why? (Same question as my previous post) -- Tzu-Chien Chiu, 3D Graphics Hardware Architect <URL:http://www.csie.nctu.edu.tw/~jwchiu>