llvm dev - Jul 2007 - [LLVMdev] use/def/kill problem in LiveVariables.cpp

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.

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.

Dan

-- 
Dan Gohman, Cray Inc.

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