[LLVMdev] <IsKill> getting from MachineOperand is just <Used> attribute from logic.

Jakob Stoklund Olesen stoklund at 2pi.dk
Thu Jan 14 19:44:39 PST 2010

On Jan 14, 2010, at 6:39 PM, 任坤 wrote:

> But I want do some optimization after register alloction by adjusting 
> register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg.

You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same thing.

>  R4 is marked <kill> at MBB0.  If I scan R4's liverange by [MBB0->MBB1->MBB2]. I will find R4 first is killed, then is used. It can not unlogisch. Attually R4 just is <Used>. It will cause my optimization pass crash(Actually, I ingore Live In message of MBB. I recollect live in messges at my pass.).

A register should not be used after it is killed, and if it is needed by a successor block, it should be live out.

Note that a register in the live-in list of an MBB is not always live-out from all predecessors. A register defined by IMPLICIT_DEF can be optimized away entirely.

>  1. Does <kill> attribute of R4 at MBB0 is a unimportant  and redundancy messages, Or a little bug???

You have probably found a bug. Can you reproduce it with one of the normal back ends?

>  2. Is it unreliable to get a physical register's liverange by Kill, Dead messages from MachineBasicBlock?? 

You also need to use the live-in list for each MBB, but otherwise it should be reliable. Look at how RegisterScavenger is doing it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100114/b0907dbf/attachment.bin>

More information about the llvm-dev mailing list