search for: findlastusebefor

Hi Sergei, I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a while since I ran live-interval-update over all of it) and try out your modifications to findLastUseBefore. Tha...

On Sep 2, 2012, at 11:52 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Sergei, > > I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. > > Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a while since I ran live-interval-update over all of it) and try out your modifications to findLastUseBefore. I t...

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Ro...

Hi Lang, Just one more quick question. in LiveIntervalAnalysis.cpp In SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) Did you really mean to use for (MachineRegisterInfo::use_nodbg_iterator UI = MRI.use_nodbg_begin(Reg), UE = MRI.use_nodbg_end(); UI != UE; UI.skipInstruction()) {} Aren't we currently dealing with units, not regis...

...PM, Lang Hames <lhames at gmail.com> wrote: > > > Hi Sergei, > > > > I just fixed the broken test case for PR13719 with r163107, but from the > debugging output you've posted it suspect it won't fix your test case. > > > > Your analysis looks good - findLastUseBefore(..) doesn't appear to be > handling physregs. I'm surprised that isn't causing more failures. I'll see > if I can find a failing case in the LLVM test-suite (it's been a while > since I ran live-interval-update over all of it) and try out your > modifications to fin...

Hi Sergei, Andy, Sorry - I got distracted with some other work. I'm looking into this and PR13719 now. I'll let you know what I find out. Sergei - thanks very much for the investigation. That should help me pin this down. Cheers, Lang. On Tue, Aug 28, 2012 at 2:33 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, Lang, > > Thanks for the suggestion. >

> On Oct 27, 2016, at 5:30 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote: >> >>> The system works because the default basic block iterator moves from bundle to >>> bundle skipping the instructions inside the bundle. Iterating

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

> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com> wrote: > > >> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: >> >> == BUNDLE instruction / operands == >> For many backend passes a bundle can appear as a single unit. However one important tool >> here is having an iterator over all operands of this