search for: spillabl

This lets us spill more values and compile a big shader for Civilization 6. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp index b33d7b4010..f29c8a1a95

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...

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 with a very high spill cost and the regalloc is able to c...

...is with Tablegen? For each instruction with two paired register operands, these combinations must be the only legal ones, but do I have to write several instruction definitions to express this?) To do away with pre-allocation, LLVM would have to be extended with an RegClass/register-attribute 'spillable', and a register allocator would have to implement register pairing. That would be PBQP, right? What's your standpoint on these extensions? I would be glad to work with you on this, when I have the time. Jonas Paulsson Ericsson -------------- next part -------------- An HT...

...wo values are not always the same. For example, Hexagon has predicate registers that are 8 bits long and vector predicate registers that are 64 or 128 bits long, but their spill slots are of different sizes. None of these registers can be spilled directly, and they have to be transferred into a spillable register first. These spillable registers are larger: 32 bits and 512/1024 bits respectively, and so getSize must return the larger value in order to handle spills correctly. Different users of getSize may be interested in different aspects of the returned value: register allocator may care a...

On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Spill-free register allocation sounds great, why not do it for all register classes? > , and a register allocator would have to implement register pairing. That would be PBQP, right? If by pai...

> On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' > > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive than saving/restoring an ordinary register. T...

...in this case. In setup(), the node is first put into not-provably-allocatables. However, one of it's neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can't be spilled. This seems intuitively wrong, as they are intervals that actually could be spilled. I would really appreciate some help and pointers on what might be going wrong here, Jonas Paulsson -------------- next part -------------- An HTML at...

...disabled optimizations, and now optimizations are missing. The fast register allocator tries very hard to be fast. That includes producing suboptimal code. Sometimes it is faster to spill than to run an expensive interference computation. > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we basically do not want to do this, and I would not have to pre-allocate. But there is probably a better way, or? I am sorry, I simply don't understand what you are asking for. You might as well suggest that we all don't pay taxes. It sounds tempt...

On Jan 7, 2013, at 4:58 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello Jakob, > > Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? It's not likely I'll have time to look at this in the near future. I'd recommend you do it yourself. /jakob > 2012/12/19 Borja Ferrer <borja.ferav at gmail.com>

Hello Jakob, Did you get a chance to take a look into this, and if not, can you do it when you get some spare time? Thanks! 2012/12/19 Borja Ferrer <borja.ferav at gmail.com> > We did something like this back when the register allocator couldn't split >> live ranges. >> > > Yes, I remember the isWinToJoinCrossClass() function, removed here: > >

...ster (problem.isPRegOption(vreg, alloc)), - or a spill (problem.isSpillOption(vreg, alloc)) The problem is that pass CalcSpillWeights can 'hint' that it is a poor idea to spill this specific register with : CalcSpillWeights.cpp / VirtRegAuxInfo::CalculateWeightAndHint : // Mark li as unspillable if all live ranges are tiny. if (li.isZeroLength(LIS.getSlotIndexes())) { li.markNotSpillable(); ... This hint makes the register non spillable at all for the spiller (that's the assert above), not just a bad-idea-to-spill-but-feasible. The pbqp allocator does not cope with this d...

...n. I am not defining just one machine but let's say a "kind" of similar machines, so I have separate cases, the number of regs that can be destination of, for example, "add", can vary from just one to several. They form the "AddRegs" class. Also, they are not spillable to stack, but they can be copied to general purpose IntRegs. Say I have two additions on my code, and just one reg in AddRegs. The RA would run out of registers, so I change the ISel in a way the adds are selected to my machineinstr going to AddRegs followed by a move to IntRegs. I want t...

...etup(), the node is first put into not-provably-allocatables. > However, one of it’s neigbhour invoked handleDisconnectEdge(), and moves it > into conservatively-allocatables, because DeniedOpts had become less than > NumOpts (in isConservativelyAllocatable(). > > * There are lots of spillable nodes being popped before the one that can’t > be spilled. This seems intuitively wrong, as they are intervals that > actually could be spilled. > > > > I would really appreciate some help and pointers on what might be going > wrong here, > > > > Jonas Paulsson &g...

...force rematerialization by extending live intervals. For example: %vreg1 = opa %vreg2, %vreg3 ; RClassA:%vreg1, RClassB:%vreg2, RClassB:%vreg3 ... somewhere between --> %vreg2<kill> and %vreg3<kill> .. %vreg4 = opb %vreg1 ; RClassA:%vreg1, RClassB:%vreg4 In my case, %vreg1 is not spillable and I'd like to extend vreg2 and vreg3 live intervals to get "opa" rematerialized. If I understand correctly, the InlineSpiller only rematerializes if all the operands values of "opa" reach "opb", right ? How can I extend the live interval of some VR even if i...

...t in this case. In setup(), the node is first put into not-provably-allocatables. However, one of it’s neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can’t be spilled. This seems intuitively wrong, as they are intervals that actually could be spilled. I would really appreciate some help and pointers on what might be going wrong here, Jonas Paulsson -------------- next part -------------- An...

On Sep 13, 2010, at 6:59 AM, Carlos Sánchez de La Lama wrote: > Hi people, > > the LinearScan register allocator tries to use same register for both > live intervals, if the new interval is defined by a register copy > whose destination reg is compatible with the source register. This is > ok. However, this "check for compatibility" is wrongly done IMHO. >

On Feb 11, 2009, at 4:07 AM, Alex wrote: > In my hardware there are two special registers cannot be copied but > can only be assigned and referenced (read) in the other instruction. > They are allocatable also. > > br i1 %if_cond, label %then, label %else > then: > %x1 = fptosi float %y1 to i32 > br label %endif > else: > %x2 = fptosi float %y2 to i32 >

...2 <==== rename INT2 to INT1 mul R0, R[INT1+2], R[INT0+1] I use the method suggested in "Kaleidoscope: Extending the Language: Mutable Variables" (http://llvm.org/docs/tutorial/LangImpl7.html) and rely on mem2reg to promote these loads to registers. By the way, all registers are non-spillable. -- View this message in context: http://www.nabble.com/Eliminate-PHI-for-non-copyable-registers-tp21953583p21972748.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

Hi Arnaud, LiveInterval::markNotSpillable() sets the live interval's spill weight to infinity. For well-formed PBQP graphs (i.e. ones that have some finite-cost solution), PBQP should never chose to spill such an interval. The two possibilities for this crash are that the input graph has no finite-cost solution, or that you've exp...