search for: bb74

Ok, I understand a bit more of what's going on in my phi example. Coming into DAGtoDAG we have this code: bb74: x = phi(1.0:bb134, %r1450:bb108) y = phi(undef:bb134, x:bb108) [...] bb108: %r1450 = <expr> After DAGtoDAG we have: bb134: %reg1459 = IMPLICIT_DEF %reg1458 = 1.0 bb74: %reg1176 = phi(%reg1458:bb134, %reg1253:bb108) %reg1177 = phi(%reg1459:bb134, %reg1176:bb108) [...] bb108...

...ly define any value. So we don't > care if a live interval overlaps live ranges defined by an implicit_def. It's a bug because the coalerscer does illegal coaescing. Our last episode left us here: 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....

On Monday 02 February 2009 23:55, Evan Cheng wrote: > >> Think about what will happen the 2nd iteration.  %v1177 will have > >> the value of > >> %v1645 which is wrong.  This is because %v1176 in bb74 will be > >> replaced with > >> %v1177.  That's incorrect. > > > > Ok, right. The trick to fixing is to make sure the valno of the def of > > v1177 hasPHIKill to true and make sure the coalescer checks it. What does hasPHIKill mean, what are the consequences...

...9;s totally legal for >> v1177 has the same value as v1176. It's defined by an undef, it's >> allowed to have contain any value. > > Think about what will happen the 2nd iteration. %v1177 will have > the value of > %v1645 which is wrong. This is because %v1176 in bb74 will be > replaced with > %v1177. That's incorrect. Ok, right. The trick to fixing is to make sure the valno of the def of v1177 hasPHIKill to true and make sure the coalescer checks it. Evan > > > -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 = >>

On Thursday 29 January 2009 18:04, Eli Friedman wrote: > On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: > > After phi elimination we have: > > > > bb134: > > %reg1645 = 1.0 > > > > bb74: > > %reg1176 = MOVAPS %reg1645 > > %reg1177 = MOVAPS %reg1646 > > [...] > > > > bb108: > > %reg1645 = <expr> > > %reg1646 = %reg1176 > > I find it a little strange that the IMPLICIT_DEF disappears. Besides > that, it looks okay up to he...

...>>> v1177 has the same value as v1176. It's defined by an undef, it's >>> allowed to have contain any value. >> >> Think about what will happen the 2nd iteration. %v1177 will have >> the value of >> %v1645 which is wrong. This is because %v1176 in bb74 will be >> replaced with >> %v1177. That's incorrect. > > Ok, right. The trick to fixing is to make sure the valno of the def of > v1177 hasPHIKill to true and make sure the coalescer checks it. Actually liveintervals can construct a v1177 live range starting from the b...

..., David Greene wrote: > On Thursday 29 January 2009 18:04, Eli Friedman wrote: >> On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: >>> After phi elimination we have: >>> >>> bb134: >>> %reg1645 = 1.0 >>> >>> bb74: >>> %reg1176 = MOVAPS %reg1645 >>> %reg1177 = MOVAPS %reg1646 >>> [...] >>> >>> bb108: >>> %reg1645 = <expr> >>> %reg1646 = %reg1176 >> >> I find it a little strange that the IMPLICIT_DEF disappears. Besides >>...

...live interval overlaps live ranges defined by an >> implicit_def. > > It's a bug because the coalerscer does illegal coaescing. > > Our last episode left us here: > > 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...

On Thu, Jan 29, 2009 at 2:47 PM, David Greene <dag at cray.com> wrote: > After phi elimination we have: > > bb134: > %reg1645 = 1.0 > > bb74: > %reg1176 = MOVAPS %reg1645 > %reg1177 = MOVAPS %reg1646 > [...] > > bb108: > %reg1645 = <expr> > %reg1646 = %reg1176 I find it a little strange that the IMPLICIT_DEF disappears. Besides that, it looks okay up to here. > Should llvm be able to handle situation...

...n the first iteration, it's totally legal for > v1177 has the same value as v1176. It's defined by an undef, it's > allowed to have contain any value. Think about what will happen the 2nd iteration. %v1177 will have the value of %v1645 which is wrong. This is because %v1176 in bb74 will be replaced with %v1177. That's incorrect. -Dave

On Feb 5, 2009, at 5:30 PM, David Greene wrote: > On Monday 02 February 2009 23:55, Evan Cheng wrote: > >>>> Think about what will happen the 2nd iteration. %v1177 will have >>>> the value of >>>> %v1645 which is wrong. This is because %v1176 in bb74 will be >>>> replaced with >>>> %v1177. That's incorrect. >>> >>> Ok, right. The trick to fixing is to make sure the valno of the >>> def of >>> v1177 hasPHIKill to true and make sure the coalescer checks it. > > What does has...

On Feb 2, 2009, at 12:12 PM, David Greene wrote: > On Monday 02 February 2009 13:14, Evan Cheng wrote: > >> I am sorry I don't really follow it. Is this what you are describing? >> >> %v1177 = undef >> ... >> loop: >> ... >> %v1176 = op ... >> = %v1177 >> %v1177 = %v1176 >> jmp loop >> >> Why is not

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