Handling of KILL instructions.

Hi all,

My understanding is that we keep around KILL instructions in order to keep
the results of the various register liveness analysis passes valid.

Consider for example the following machine basic block:

BB#0: derived from LLVM BB %entry
    Live Ins: %A0_64 %A1_64
        %V0_64<def> = AND64 %A0_64<kill>, %A1_64<kill>
        %V0<def> = KILL %V0, %V0_64<imp-use,kill>
        PseudoReturn64 %RA_64

In this case we would like to move the AND64 instruction after the KILL
instruction (generated from an identity COPY).

What is the right thing to do with the KILL instruction given the fact that
the machine function pass calls TRI.invalidateLiveness()? Can we simply
delete any KILL instruction we want? Or, can we ignore them as long as we
don't request any register liveness analysis in subsequent machine function
passes?

-- Vasileios Kalintiris

Ping.

To give some additional context, the KILL instructions are blocking
candidates for the filling of delay slots in the Mips and the Sparc
backends. Despite the fact that the delay slot filler pass is running
immediately before machine code is emitted (registered with
addPreEmitPass()), there are some backend specific machine function
passes that have to run *after* the delay slot filler. This is why the
handling of KILL instructions is relevant in our case.

-- Vasileios Kalintiris

Hi Vasileios,

If you start moving instruction around, then I suggest you remove the kill instructions. Otherwise, if the liveness gets recomputed later on, you may have bad surprises, same thing with the MachineVerifier.

Cheers,
-Quentin

If you start moving instruction around, then I suggest you remove the kill instructions

Thank you Quentin! That was what I intended to do.

Otherwise, if the liveness gets recomputed later on, you may have bad surprises, same thing with the MachineVerifier.

I suppose another option would be to move in-order both instructions to the target destination. However, I'm not sure if it would be useful at all because we would have to recompute liveness nevertheless. Also, we would violate the semantic notion of what is a delay slot, i.e. we would end up with 2 or more instructions in the delay slot.

-- Vasileios Kalintiris