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
On Thursday 21 February 2008 01:23, Evan Cheng wrote:> > 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.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).MergeInClobberRanges(*ResSrcInt, > li_-Yep.> >getVNInfoAllocator()); > > Can you take a look at MergeInClobberRanges() to see what is going on? > Otherwise, please file a bug with a test case.Yes. I think I know what's going on. This happens in SPEC 2006 bwaves on the block_solver.f source file. This is of course using our frontend and optimizer, so it may not be reproducable for anyone else. I'll see if I can generate a .ll testcase. The llvm tools probably won't fail because they don't contain the assert that I have in my code. Here are the steps of what happens in MergeInClobberRanges: 1. IP = [0,10:0 [0]) (begin() for %reg15) 2. I = [458,5168:0 [0]) (begin() for %reg1026) 3. Start = 458, End = 5168 4. IP = [938,942:1 [0]) (std::upper_bound(IP, end(), Start) 5. IP != begin() && IP[-1].end > Start is FALSE 6. IP != end() && End > IP->start is TRUE 7. End = 938 (IP->start) 8. Start == End is FALSE 9. IP = [458,938:89 [0]) (addRangeFrom(LiveRange(Start, End, ClobberValNo), IP)) 10. We are now done processing [458,5168:0 [0]) from %reg1026 but we didn't process the part of the interval AFTER 938, where the overlap with %reg15 ends! This comment seems strange to me: // If the end of this range overlaps with an existing liverange, trim it. There's a similar comment about trimming the start of the Clobbers live range. 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. So what's the right answer? -Dave
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 [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,2343:16 [0])[3366,3370:17 [0]) [3370,3371:18 [0])[3390,3394:19 [0])[3394,3395:20 [0])[3642,3646:21 [0]) [3646,3647:22 [0])[3666,3670:23 [0])[3670,3671:24 [0])[3942,3946:25 [0]) [3946,3947:26 [0])[3966,3970:27 [0])[3970,3971:28 [0]) They all have different value numbers. How should this get merged in this case? Do we process each of these live ranges against [458,5168:0 [0]) using the existing code? What do we do with the holes between them? Fill them with new ranges that have an unknown definition value? -Dave
Seemingly Similar 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