search for: getrematimplicitus

I'm working on some enhancements to rematerialization that I hope to contribute. It's mostly working but I am running into one problem. It boils down to having spilled a register used by the remat candidate. I thought this is what getReMatImplicitUse is supposed to handle but it looks inconsistent to me. The comment says this: /// getReMatImplicitUse - If the remat definition MI has one (for now, we only /// allow one) virtual register operand, then its uses are implicitly using /// the register. Returns the virtual register. unsigned LiveIn...

...> I'm working on some enhancements to rematerialization that I hope to > contribute. What do you have in mind? > It's mostly working but I am running into one problem. It > boils down to having spilled a register used by the remat candidate. > > I thought this is what getReMatImplicitUse is supposed to handle but > it looks inconsistent to me. The comment says this: > > /// getReMatImplicitUse - If the remat definition MI has one (for now, we only > /// allow one) virtual register operand, then its uses are implicitly using > /// the register. Returns the virtual...

...kob 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) virtual register operand, then its uses are implicitly using >> /// the register. Returns the virtual register. >> unsigned LiveIntervals::getReMatImplicitUse(const LiveInterval &li, >>...

...-simplified.bc > > Any ideas about the reasons of this bug? > > Thanks, > -Roman It looks like it is trying to rematerialize a load from fixed stack slot (LDWSP instruction). This has an implicit use of the SP register which is non allocatable. rewriteInstructionsForSpills calls getReMatImplicitUse which returns the SP register. This is then followed by a call to getInterval for this register which fails. The attached patch causes getReMatImplicitUse to ignore non allocatable physical registers, which fixes the issue for me. Does this look OK? -- Richard Osborne | XMOS http://www.xmos....

...out the reasons of this bug? >> >> Thanks, >> -Roman > It looks like it is trying to rematerialize a load from fixed stack > slot (LDWSP instruction). This has an implicit use of the SP > register which is non allocatable. > > rewriteInstructionsForSpills calls getReMatImplicitUse which returns > the SP register. This is then followed by a call to getInterval for > this register which fails. The attached patch causes > getReMatImplicitUse to ignore non allocatable physical registers, > which fixes the issue for me. Does this look OK? This patch assumes...

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I

...t; Thanks, >>> -Roman >>> >> It looks like it is trying to rematerialize a load from fixed stack >> slot (LDWSP instruction). This has an implicit use of the SP >> register which is non allocatable. >> >> rewriteInstructionsForSpills calls getReMatImplicitUse which returns >> the SP register. This is then followed by a call to getInterval for >> this register which fails. The attached patch causes >> getReMatImplicitUse to ignore non allocatable physical registers, >> which fixes the issue for me. Does this look OK? >...