On Friday 30 January 2009 01:41, Evan Cheng wrote:> >> I find it a little strange that the IMPLICIT_DEF disappears. Besides > >> that, it looks okay up to here. > > > > I just verified that it does disappear. > > It's intentional. We don't want a live interval defined by an > implicit_def. It unnecessarily increases register pressure.Ah, I see. But coalescing seems to break. I don't know if it's because of the eliminated IMPLICIT_DEF, though. Here's what happens. Let's look at this code, annotated with live range indices: bb134: 2696 %reg1645<def> = FsMOVAPSrr %reg1458<kill> ; srcLine 0 bb74: 2700 %reg1176<def> = FsMOVAPSrr %reg1645<kill> ; srcLine 0 2704 %reg1177<def> = FsMOVAPSrr %reg1646<kill> ; srcLine 0 *** u before d 2708 %reg1178<def> = FsMOVAPSrr %reg1647<kill> ; srcLine 0 *** u before d 2712 TEST64rr %reg1173, %reg1173, %EFLAGS<imp-def> ; srcLine 30 2716 JLE mbb<file test.f90, bb90,0x3c37ed0>, %EFLAGS<imp-use,kill> ; srcLine 0 bb108: [...] 4352 %reg1253<def> = MAXSSrr %reg1253, %reg1588<kill> ; srcLine 60 4356 %reg1645<def> = FsMOVAPSrr %reg1253<kill> ; srcLine 0 4360 %reg1646<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 4364 %reg1647<def> = FsMOVAPSrr %reg1243<kill> ; srcLine 0 4368 JMP mbb<file test.f90, bb74,0x3c63a60> ; srcLine 0 Coalescing comes along and says this: 2704 %reg1177<def> = FsMOVAPSrr %reg1646<kill> ; srcLine 0 Inspecting %reg1646,0 = [2700,2706:0)[4362,4372:0) 0 at 4362-(2706) and %reg1177,0 = [2706,3712:0)[3768,3878:0) 0 at 2706-(3878): Joined. Result = %reg1177,0 = [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878) Ok, that seems reasonable. The code now looks like this: bb134: 2696 %reg1645<def> = FsMOVAPSrr %reg1458<kill> ; srcLine 0 bb74: 2700 %reg1176<def> = FsMOVAPSrr %reg1645<kill> ; srcLine 0 [deleted copy] 2708 %reg1178<def> = FsMOVAPSrr %reg1647<kill> ; srcLine 0 *** u before d 2712 TEST64rr %reg1173, %reg1173, %EFLAGS<imp-def> ; srcLine 30 2716 JLE mbb<file test.f90, bb90,0x3c37ed0>, %EFLAGS<imp-use,kill> ; srcLine 0 bb108: [...] 4352 %reg1253<def> = MAXSSrr %reg1253, %reg1588<kill> ; srcLine 60 4356 %reg1645<def> = FsMOVAPSrr %reg1253<kill> ; srcLine 0 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 *** updated 4364 %reg1647<def> = FsMOVAPSrr %reg1243<kill> ; srcLine 0 4368 JMP mbb<file test.f90, bb74,0x3c63a60> ; srcLine 0 This still looks correct. The coalescer then says: 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 Inspecting %reg1176,0 = [2702,4362:0) 0 at 2702-(4362) and %reg1177,0 = [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878): Joined. Result = %reg1177,0 = [2700,4372:0) 0 at 2702-(4362) Eh? How can it coalesce these two? Doesn't %reg1176:[2702,4362:0) overlap %reg1177:[2700,3712:0)? I will look into this further. Just wanted to check in and make sure. -Dave
On Friday 30 January 2009 15:10, David Greene wrote:> This still looks correct. The coalescer then says: > > 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 > Inspecting %reg1176,0 = [2702,4362:0) 0 at 2702-(4362) and %reg1177,0 > [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878): > Joined. Result = %reg1177,0 = [2700,4372:0) 0 at 2702-(4362) > > Eh? How can it coalesce these two? Doesn't %reg1176:[2702,4362:0) overlap > %reg1177:[2700,3712:0)? > > I will look into this further. Just wanted to check in and make sure.Ok, the Coalescer thinks %reg1177 value number 0 is defined by a copy from %reg1176. I guess that could be considered correct because %reg1177 is defined by a copy from %reg1176 in bb108. It thus considers the intervals to not interfere. But this can't be right. I think the problem is that there should be two value numbers for %reg1177. We already have VN 0 defined from %reg1176. What coalescing is missing is that %reg1177 is ALSO defined by an implicit def from bb134. That's the value number we're missing and is why coalescing incorrectly removed the copy. So it appears we can't get rid of the IMPLICIT DEF. Evan, do you agree? -Dave
On Jan 30, 2009, at 1:52 PM, David Greene wrote:> On Friday 30 January 2009 15:10, David Greene wrote: > >> This still looks correct. The coalescer then says: >> >> 4360 %reg1177<def> = FsMOVAPSrr %reg1176<kill> ; srcLine 0 >> Inspecting %reg1176,0 = [2702,4362:0) 0 at 2702-(4362) and >> %reg1177,0 >> [2700,3712:0)[3768,3878:0)[4362,4372:0) 0 at 4362-(3878): >> Joined. Result = %reg1177,0 = [2700,4372:0) 0 at 2702-(4362) >> >> Eh? How can it coalesce these two? Doesn't %reg1176:[2702,4362:0) >> overlap >> %reg1177:[2700,3712:0)? >> >> I will look into this further. Just wanted to check in and make >> sure. > > Ok, the Coalescer thinks %reg1177 value number 0 is defined by a > copy from > %reg1176. I guess that could be considered correct because %reg1177 > is > defined by a copy from %reg1176 in bb108. It thus considers the > intervals to > not interfere. > > But this can't be right. I think the problem is that there should > be two > value numbers for %reg1177. We already have VN 0 defined from > %reg1176. > What coalescing is missing is that %reg1177 is ALSO defined by an > implicit def > from bb134. That's the value number we're missing and is why > coalescing > incorrectly removed the copy.I don't have the whole context to understand why you think this is a bug. An implicit_def doesn't actually define any value. So we don't care if a live interval overlaps live ranges defined by an implicit_def. That said, the way we models undef in machine instruction has always bugged me. I thought about adding a MachineOperand type to represent undef. Then we don't have to muddle the semantics of a "def". To me, that's a cleaner representation, but it will require work. Evan> > > So it appears we can't get rid of the IMPLICIT DEF. Evan, do you > agree? > > -Dave > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev