[LLVMdev] undefs in phis

Evan Cheng evan.cheng at apple.com
Mon Feb 2 21:55:46 PST 2009


On Feb 2, 2009, at 3:54 PM, Evan Cheng wrote:

>
> On Feb 2, 2009, at 1:05 PM, David Greene wrote:
>
>> On Monday 02 February 2009 14:29, Evan Cheng wrote:
>>> 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 safe to coalesce the 2 registers?
>>>>
>>>> Not quite.  The original code is:
>>>>
>>>> %v1177 = undef
>>>> %v1645 =  ...
>>>> loop:
>>>> %v1176 = %v1645
>>>> ...
>>>> = %v1176
>>>> = %v1177
>>>> %v1645 = op ...
>>>> %v1177 = %v1176
>>>> jmp loop
>>>>
>>>> We can't coalesce %v1177 and %v1176 legally.  But we do.
>>>
>>> Seriously, why not? In 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.
>
> 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 beginning mbb with a val# of unknown def.

Evan

>
> Evan
>
>>
>>
>>                                             -Dave
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list