search for: reg15

...he > purposes of coalescing? > > > In any event, it seems not to be working right if what you > describe is supposed to be happening. > > Given the two intervals in my example, which should happen > with the two overlappring ranges > > %reg1026: [458,5168:0 [0]) > %reg15: [938,942:1 [0]) > > My assumption was that after MergeInClobberRanges that %reg15 > would contain [458,5168:0 [0]). But it doesn't. So this is the call site? // Update the liveintervals of sub-registers. for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++A...

...virtual one the first thing it check is sub-registers. Right. I'm just wondering why LiveIntervalAnalysis doesn't do this as well. It's not a big deal, because I think LiveIntervalAnalysis is ok as-is. Just curious. > > My assumption was that after MergeInClobberRanges that %reg15 > > would contain [458,5168:0 [0]). But it doesn't. > > So this is the call site? > > // Update the liveintervals of sub-registers. > for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++AS) > li_->getOrCreateInterval(*AS).MergeInClobbe...

On Thursday 21 February 2008 10:53, David Greene wrote: > Why do we do this trimming? The comment seems to say we don't care about > the rest of the live range from Clobbers (%reg1026 in this case) but that > doesn't match with our expectation that %reg15 will contain all of the live > range information from %reg1026. I'll add that merging this correctly could get tricky. %reg15 contains the following live ranges, all of which overlap [458,5168:0 [0]) from %reg1026: [938,942:1 [0])[942,943:2 [0])[962,966:3 [0])[966,967:4 [0])[1242,1246:5...

...his just supposed to be a conservative update for the purposes of coalescing? In any event, it seems not to be working right if what you describe is supposed to be happening. Given the two intervals in my example, which should happen with the two overlappring ranges %reg1026: [458,5168:0 [0]) %reg15: [938,942:1 [0]) My assumption was that after MergeInClobberRanges that %reg15 would contain [458,5168:0 [0]). But it doesn't. -Dave

...ad that as, "merge in the range information from the eliminated live interval to the subregister live interval," but that appears to not be what happens. In my case, I have the following two intervals which are being coalesced: %reg1026,0 = [458,5168:0 [0])[5180,15248:0 [0]) 0 at 458 %reg15,inf = [0,10:0 [0])[10,458:87 [0])[938,942:1 [0])[942,943:2 [0]) [962,966:3 [0])[966,967:4 [0])[1242,1246:5 [0])[1246,1247:6 [0])[1266,1270:7 [0])[1270,1271:8 [0])[1578,1582:9 [0])[1582,1583:10 [0])[1602,1606:11 [0]) [1606,1607:12 [0])[2314,2318:13 [0])[2318,2319:14 [0])[2338,2342:15 [0]) [2342,234...

On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. I want >> to know if that assert is bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister

...sday 21 February 2008 10:53, David Greene wrote: > >> Why do we do this trimming? The comment seems to say we don't care >> about >> the rest of the live range from Clobbers (%reg1026 in this case) >> but that >> doesn't match with our expectation that %reg15 will contain all of >> the live >> range information from %reg1026. > > I'll add that merging this correctly could get tricky. %reg15 > contains the > following live ranges, all of which overlap [458,5168:0 [0]) from > %reg1026: > > [938,942:1 [0])[942,9...

On Wed, 21 Oct 2009, Lang Hames wrote: > There are any number of things that can go wrong in register allocation, so > it's hard for me to guess without seeing your code. > > Possible issues: > > 2) How are you making sure that interfering virtregs never receive the same > physreg? If you're using the LiveIntervals analysis (and the >

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register