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
On Feb 21, 2008, at 9:06 AM, David Greene wrote:> 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?All of the new ranges, including values, should be from the new val# defined by an unknown instruction. This does prevent further coalescing but should be correct. 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 Friday 22 February 2008 02:41, Evan Cheng wrote:> All of the new ranges, including values, should be from the new val# > defined by an unknown instruction. This does prevent further > coalescing but should be correct.Ok. I'm working on a fix for this. I think I'm close. -Dave
Reasonably Related 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