search for: mcregunititerator

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units)) collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); } else { // Collect ranges for individual virtual registers. collectRanges(MO, &LIS.getInt...

...rora.org> wrote: > The code in collectRanges() does: > > // Collect ranges for register units. These live ranges are computed on > // demand, so just skip any that haven't been computed yet. > if (TargetRegisterInfo::isPhysicalRegister(Reg)) { > for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) > if (LiveInterval *LI = LIS.getCachedRegUnit(*Units)) > collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); > } else { > // Collect ranges for individual virtual registers. > collectRanges...

...y The Linux Foundation > -----Original Message----- > From: Arnold Schwaighofer [mailto:arnolds at codeaurora.org] > Sent: Thursday, August 30, 2012 2:43 PM > To: Sergei Larin > Cc: Jakob Olesen; LLVM Developers Mailing List > Subject: Re: [LLVMdev] MC Register mapping question (MCRegUnitIterator > ) > > Hi Sergei, > > Register units != sub registers. > > Register units are an abstraction to describe overlapping of registers > effectively. > > You probably wanted to use MCSubRegIterator. > > > On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <sla...

...gisters. Register units are an abstraction to describe overlapping of registers effectively. You probably wanted to use MCSubRegIterator. On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hello Jakob and everyone, > > I am observing an issue with MCRegUnitIterator in my back end, and trying > to reverse engineer some of the table gen magic around it, but if you or > someone readily knows the answer, I would highly appreciate it. > > Here is the problem. > > In my back end we have a rather simple int register file structure: > > // I...

Hello Jakob and everyone, I am observing an issue with MCRegUnitIterator in my back end, and trying to reverse engineer some of the table gen magic around it, but if you or someone readily knows the answer, I would highly appreciate it. Here is the problem. In my back end we have a rather simple int register file structure: // Integer registers. def R0 : Ri< 0...

Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)...

...trigger on interaction with a '0' interval? That could introduce some subtle bugs. Right. Regunits are numbered independently from physregs, starting from 0. Each regunit corresponds to one or two physregs, the 'roots', which are typically leaf registers. The mapping is exposed by MCRegUnitIterator and MCRegUnitRootIterator. Regunit live intervals are more strictly defined than the old physreg intervals. The same way a virtreg interval can be computed from all machine operands mentioning the virtreg, regunit intervals can be computed from all physreg operands with TRI->hasRegUnit(MO.getRe...

Hi Jakob, I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could

On 24 May 2013 17:39, Chad Rosier <mcrosier at apple.com> wrote: > One side effect of dynamically computing the aliases is that the iterator > does not guarantee that the entries are ordered or that duplicates have > been removed. > Hi Chad, Sounds like you're growing the list (thus the lookup time), rather than shrinking, as I take it was Jacob's original intention?