[LLVMdev] Handling of KILL instructions.

[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

________________________________________
From: Vasileios Kalintiris
Sent: 04 February 2015 11:11
To: llvmdev at cs.uiuc.edu
Cc: ehostunreach at gmail.com; Daniel Sanders
Subject: 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