[LLVMdev] Live intervals and aliasing registers problem

Evan Cheng evan.cheng at apple.com
Wed Apr 4 11:38:11 PDT 2007

On Apr 3, 2007, at 3:45 PM, Christopher Lamb wrote:

>> Can you dump out the machine basic block? It should have an
>> implicit use of V4R0 at first ORI but it should not be marked kill.
>> If it is marked kill, then you need to walk LiveVariables.cpp to
>> find out why.
> Here is the beginning of the BB dump.
> entry (0x8503c80, LLVM BB @0x8501af0, ID#0):
> Live Ins: %R0 %R1
> 	%reg1024 = ORI %R0<kill>, 0
> 	%reg1025 = ORI %R1<kill>, 0
> V4R0 is getting killed because handleLiveInRegister() is called on
> all results of getAliasSet() for each of the liveins (this is in
> LiveIntervals::computeIntervals() ).
> handleRegisterDef() does a similar thing where calls
> handlePhysicalRegisterDef() on all members of getAliasSet() returned
> for the def, which also triggers this problem.
> Is it calling handle*() on the alias set of a register thats the
> culprit, or is it some mishandling in KillsRegister()?

This is a pretty serious bug. LiveVariables::KillsRegister should not  
kill aliases that are "larger". The correct way to fix this is to  
explicitly list registers that are defined, used, and killed. So your  
example should look like:

entry (0x8503c80, LLVM BB @0x8501af0, ID#0):
Live Ins: %R0 %R1
	%reg1024 = ORI %R0<kill>, 0, %V4R0<imp-use>
	%reg1025 = ORI %R1<kill>, 0, %V4R0<imp-use,kill>

KillsRegister should check for exact match rather than regsOverlap.  
There are probably other similar bugs in LiveVariables.

Please file a bug, I'll look at after I get back from vacation in a  


> Thanks
> --
> Christopher Lamb
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070404/f137d16b/attachment.html>

More information about the llvm-dev mailing list