[LLVMdev] use/def/kill problem in LiveVariables.cpp

Evan Cheng evan.cheng at apple.com
Mon Jul 9 11:17:08 PDT 2007


On Jul 9, 2007, at 7:29 AM, Dan Gohman wrote:

> In LiveVariables.cpp, when traversing the instructions, all defs of  
> registers
> are initially marked as kills. See the code around the comment
> "Defaults to dead". Then later on, when a pass changes  
> instructions, the
> LiveVariables code updates the kills lists, but it only does so for  
> uses, not
> defs. See the code around the comment
> "If this is a kill of the value, update the VI kills list."
>
> I'm seeing a case where an instruction is being deleted -- and  
> actually
> C++-delete-keyword deleted -- but not taken out of the kills list for
> instructions which have kills due to defs, following the above.  
> That leaves
> a dangling pointer in the kills list, which is big trouble.

Ok. Sounds like a bug. :-)

>
> I don't yet have a standalone test case which reproduces the  
> problem, though
> I'll try to make one. So far this problem has only been visible in  
> very large
> programs.
>
> I have a fix, which is to remove the "if (MO.isUse())" test around  
> the code
> that updates the kills list, causing it to attempt to do this for  
> both uses
> and defs, but I'd like to understand this problem better.
>
> Why are kills entries added for defs in the first place? Is it  
> expected that
> there will always be uses to take over the kill from a def? I have  
> some
> guesses, but I'm interested to hear from anyone more familiar with  
> the code.

Looks like the kills set encompass of both "real" kills (i.e. last  
use) as well as definition of dead def's. While the naming is not  
ideal, it's probably ok. I believe your proposed solution is correct  
but it requires lots of testing to know for sure.

Evan

>
> Dan
>
> -- 
> Dan Gohman, Cray Inc.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list