RegisterCoalescer, multple defs of different subregisters, some are dead

Project Infrastructure LLVM Dev List Archives
#1

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@288r 1@128r 2@400B-phi weight:0.000000e+00

LHS = %23 [16r,288r:2)[288r,288d:4)[320r,400B:3)[400B,480r:0)[480r,496r:1) 0@400B-phi 1@480r 2@16r 3@320r 4@288r weight:0.000000e+00

merge %19:2@400B into %23:0@400B → @400B

merge %23:1@480r into %19:2@400B → @400B

merge %23:4@288r into %19:0@288r → @288r

pruned %19 at 320r: [128r,160B:1)[288r,320r:0)[400B,480r:2) 0@288r 1@128r 2@400B-phi

pruned all of %23 at 288r: [16r,288r:2)[320r,400B:3)[400B,480r:0)[480r,496r:1) 0@400B-phi 1@480r 2@16r 3@320r 4@288r

pruned %23 at 128r: [16r,128r:2)[160B,288r:2)[320r,400B:3)[400B,480r:0)[480r,496r:1) 0@400B-phi 1@480r 2@16r 3@320r 4@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@400B-phi 1@16r 2@288r 3@320r 4@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@192r 1@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@400B-phi 1@16r 2@288r 3@320r 4@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:

#2

# 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