llvm dev - Sep 2018 - RegisterCoalescer, multple defs of different subregisters, some are dead

I've ran into this situation for our out-of-tree target.
(The first part is just some background info describing what is happening. My
actual questions are at the end.)

We got an instruction like this during register coalescing

288B      %19:an40_0_7, dead %23.hiAcc40:an40pairs = div_i32_p4
%23.hiAcc40:an40pairs, %22:an40_0_7

and the we get this merge:

               Considering merging to aN40Pairs with %19 in %23:loAcc40
                              RHS = %19 [128r,160B:1)[288r,400B:0)[400B,480r:2) 
0 at 288r 1 at 128r 2 at 400B-phi weight:0.000000e+00
                              LHS = %23
[16r,288r:2)[288r,288d:4)[320r,400B:3)[400B,480r:0)[480r,496r:1)  0 at 400B-phi
1 at 480r 2 at 16r 3 at 320r 4 at 288r weight:0.000000e+00
                              merge %19:2 at 400B into %23:0 at 400B -->
@400B
                              merge %23:1 at 480r into %19:2 at 400B -->
@400B
                              merge %23:4 at 288r into %19:0 at 288r -->
@288r
                              pruned %19 at 320r:
[128r,160B:1)[288r,320r:0)[400B,480r:2)  0 at 288r 1 at 128r 2 at 400B-phi
                              pruned all of %23 at 288r:
[16r,288r:2)[320r,400B:3)[400B,480r:0)[480r,496r:1)  0 at 400B-phi 1 at 480r 2
at 16r 3 at 320r 4 at 288r
                              pruned %23 at 128r:
[16r,128r:2)[160B,288r:2)[320r,400B:3)[400B,480r:0)[480r,496r:1)  0 at 400B-phi
1 at 480r 2 at 16r 3 at 320r 4 at 288r
                              erased:  480r       %23.acc:an40pairs = COPY
%19.acc:an40_0_7
                              restoring liveness to 5 points:
400B,320r,288d,160B,128r:  %23
[16r,128r:1)[128r,160B:4)[160B,288r:1)[288r,320r:2)[320r,400B:3)[400B,496r:0)  0
at 400B-phi 1 at 16r 2 at 288r 3 at 320r 4 at 128r weight:0.000000e+00
                              updated: 128B   %23.acc:an40pairs = mv32Imm_pseudo
-1
                              updated: 288B   %23.loAcc40:an40pairs, dead
%23.hiAcc40:an40pairs = div_i32_p4 %23.hiAcc40:an40pairs, %22:an40_0_7
                              updated: 320B   %23.hiAcc40_then_acc:an40pairs =
shfts %23. loAcc40_then_acc:an40pairs, -31

so after coalescing we have

288B      %23.loAcc40:an40pairs, dead %23.hiAcc40:an40pairs = div_i32_p4
%23.hiAcc40:an40pairs, %22:an40_0_7
********** INTERVALS **********
%22 [192r,288r:0)[288r,288d:1)  0 at 192r 1 at 288r weight:0.000000e+00
%23
[16r,128r:1)[128r,160B:4)[160B,288r:1)[288r,320r:2)[320r,400B:3)[400B,496r:0)  0
at 400B-phi 1 at 16r 2 at 288r 3 at 320r 4 at 128r weight:0.000000e+00

And we get *** Bad machine code: Live range continues after dead def flag ***
(the loAcc40 subregister is live out and used later, while the hiAcc40
subregister is dead)


My questions are:


  1.  We are not tracking subregister liveness for our target. So should it be
allowed to have "%23.loAcc40:an40pairs, dead %23.hiAcc40:an40pairs =
..."? (What is the semantics for that?)

  2.  Is the semantics of a "dead" subregister def different for
"tracks subregister liveness" enable and disabled?

  3.  Would it be correct to remove the "dead" marking for
%23.hiAcc40:an40pairs in my problem above (at least with subregister liveness
disabled)? Or is the verifier that is too restrictive here?

Regards,
Björn
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180917/825827aa/attachment.html>

On 9/17/2018 12:07 PM, Björn Pettersson A via llvm-dev
wrote:
> # We are not tracking subregister liveness for our target. So should it be 
> allowed to have “%23.loAcc40:an40pairs, dead %23.hiAcc40:an40pairs = …”? 
> (What is the semantics for that?)
It should be allowed, because it can still useful to know that this 
particular def operand is dead. The semantics (in general) is that as 
long as a part of a register is live, then the register is live.
> # Is the semantics of a “dead” subregister def different for “tracks 
> subregister liveness” enable and disabled?
Tracking subregister liveness means that each subregister has its own 
live range. The containing register still has its own range (which 
should be in agreement with the live ranges of its subregisters). In 
that sense, tracking subregister liveness can reflect this situation in 
live ranges and potentially allow optimizations to take advantage of it. 
If there is a bug in treating such cases for the main register range, 
however, it may still apply with the subregister liveness tracking.
> # Would it be correct to remove the “dead” marking for 
> %23.hiAcc40:an40pairs in my problem above (at least with subregister 
> liveness disabled)? Or is the verifier that is too restrictive here?
Correct, yes, but not necessarily right. This seems like a bug in the 
verifier, actually.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation