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 live intervals for the register coaelsced to now > interfere > with whatever the eliminated live interval interfered with, since the > superregister live interval now contains information from the > eliminated live > interval and thus it interferes with whatever the eliminated live > interval > interfered with (and thuis so should the subregister live interval, > correct?). > In my case, this test _fails_, which I found to be unexpected. > > In other words, after coalescing, should it be the case that > subregister > intervals contain at least all of the range information that was > contained > in any eliminated intervals when those eliminated intervals were > coalesced > to the subregister's superregister?Right. The code is being conservative. It's saying all of the entirety of the superregister's live interval must also be in the subregister's live interval. i.e. When the superregister is live, the subregister must be live. Evan> > > If not, which is this code supposed to be doing? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
David A. Greene
2008-Feb-21 03:36 UTC
[LLVMdev] Bug? Coalescing & Updating Subreg Intervals
On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote:> > In other words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? > > Right. The code is being conservative. It's saying all of the entirety > of the superregister's live interval must also be in the subregister's > live interval. i.e. When the superregister is live, the subregister > must be live.Ok, but that is NOT what's happening in this case. Also, LiveIntervalAnalysis doesn't do any subregister checks as far as I can tell. It's certainly not the case that subregister intervals contain all of the information their supperregister's interval contains. So is this 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
On Feb 20, 2008, at 7:36 PM, David A. Greene wrote:> On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were >>> coalesced >>> to the subregister's superregister? >> >> Right. The code is being conservative. It's saying all of the >> entirety >> of the superregister's live interval must also be in the >> subregister's >> live interval. i.e. When the superregister is live, the subregister >> must be live. > > Ok, but that is NOT what's happening in this case. > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > far as I can tell. It's certainly not the case that subregister > intervals contain all of the information their supperregister's > interval contains.SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical register with a virtual one the first thing it check is sub-registers.> > > So is this 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.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, li_- >getVNInfoAllocator()); Can you take a look at MergeInClobberRanges() to see what is going on? Otherwise, please file a bug with a test case. Evan> > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Maybe Matching Threads
- [LLVMdev] Bug? Coalescing & Updating Subreg Intervals
- [LLVMdev] Bug? Coalescing & Updating Subreg Intervals
- [LLVMdev] Bug? Coalescing & Updating Subreg Intervals
- [LLVMdev] Bug? Coalescing & Updating Subreg Intervals
- [LLVMdev] Bug? Coalescing & Updating Subreg Intervals