[LLVMdev] undefs in phis

[Evan Cheng]

On Feb 2, 2009, at 10:08 AM, David Greene wrote:

> On Friday 30 January 2009 16:54, Evan Cheng wrote:
>
>> 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.
>
> 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.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)
>
> Now let's look at the resulting code:
>
> bb134:
> 2696    %reg1645<def> = FsMOVAPSrr %reg1458<kill>        ; srcLine 0
>
> bb74:
> 2700    %reg1177<def> = FsMOVAPSrr %reg1645<kill>        ; srcLine 0  
> *** u
> [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
> [deleted copy]
> 4364    %reg1647<def> = FsMOVAPSrr %reg1243<kill>        ; srcLine 0
> 4368    JMP mbb<file test.f90, bb74,0x3c63a60>   ; srcLine 0
>
> The very first instruction in bb74 is wrong.  The coalescer has said  
> that y
> always has the same value of x and that's incorrect.  y is always  
> one value
> "behind" x in the original source.
>
> The coalescer thinks it can do this because %reg1177 only has one  
> value number
> and that VN is marked as a copy from %reg1176.  What I'm saying is  
> that while
> %reg1177 really is copied from %reg1176, it also has some initial  
> value
> ("undef") coming into the loop.  That value is not captured by the  
> live
> interval information.  It's because of this value that we cannot  
> coalesce
> %reg1177 and %reg1176.  It's because of this value that %reg1177 is  
> always one
> value "behind" %reg1176.

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?

Evan

>
>
> Now, if there's some other way to tell the coalescer that the  
> coalescing is
> illegal, that's fine.  I don't care about the undef value number  
> itself.  I
> care about the coalescer behaving itself.  :)  I just don't know how  
> to tell
> the coalescer not to coalesce this without disabling all coalescings  
> of
> interfering live intervals, even those that are just copies from the  
> source
> register.
>
> Can you think of another way to fix this that's quick and easy?
>
>> 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.
>
> Long-term I don't have an opinion on what happens here.  But right  
> now I
> need to fix this.
>
>                                                 -Dave