search for: mergeinclobberranges

Why does LiveInterval::MergeInClobberRanges set the definition index as unknown? Why would the definition index not be the definition index for the range merged in from the other interval? I suppose if two ranges overlap it's not clear what to set the def index to. Perhaps it should result in two separate ranges with different def ind...

On Apr 2, 2008, at 5:09 PM, David Greene wrote: > Why does LiveInterval::MergeInClobberRanges set the definition index > as unknown? Why would the definition index not be the definition > index > for the range merged in from the other interval? I suppose if two > ranges > overlap it's not clear what to set the def index to. Perhaps it > should result > in t...

...to a situation where the imprecise information inhibits a coalescing. If you have made changes related to this, I'd love to have it. Thanks, Evan On Apr 7, 2008, at 10:52 AM, Evan Cheng wrote: > > On Apr 2, 2008, at 5:09 PM, David Greene wrote: > >> Why does LiveInterval::MergeInClobberRanges set the definition index >> as unknown? Why would the definition index not be the definition >> index >> for the range merged in from the other interval? I suppose if two >> ranges >> overlap it's not clear what to set the def index to. Perhaps it >> shoul...

...t 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; ++AS) li_->getOrCreateInterval(*AS).MergeInClobberRanges(*ResSrcInt,...

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

...ysical > register with 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).M...

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

...1859) 73 at 12838-(12842) 74 at 12842-(12843) 75 at 12866-(12870) 76 at 12870-(12871) 77 at 13102-(13106) 78 at 13106-(13107) 79 at 13130-(13134) 80 at 13134-(13135) 81 at 13390-(13394) 82 at 13394-(13395) 83 at 13414-(13418) 84 at 13418-(13419) 85 at 15374-(15382) 86 at 15382-(15383) 87@? 88@? MergeInClobberRanges comes along and sees that [458,5168:0 [0]) from %reg1026 overlaps [938,942:1 [0]) from %reg15. It then proceeds to add [458,938:89 [0]) to %reg15. It then moves on to the next LiveRange of %reg1026. Huh? What happened to the rest of [458,5168:0 [0])? Doesn't the subreg live interval need t...