[LLVMdev] undefs in phis

[Evan Cheng]

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