[LLVMdev] StackColoring remaps debug info from unrelated functions

Stefan Hepp stefan at stefant.org
Sun Sep 29 13:40:12 PDT 2013


I run into a a strange error when compiling with debug infos, where LLC 
tries to generate a variable DIE using a completely wrong frame-index 
(DebugDwarf tries to resolve frame index 27 in a simple function which 
only has a single frame object .. ).

After digging around, I found that MachineModuleInfo has a 
VariableDbgInfo map, that is filled by SelectionDAGBuilder.
MMI->VariableDbgInfo maps MDNodes representing variables to a 
<FrameIndex, DebugLoc> pair. All infos of all functions reside in a 
single map per module.

In lib/CodeGen/StackColoring.cpp:493 is the only place where this 
information is updated (I am using LLVM 3.3, but the code seems to be 
the same in trunk).

StackColoring::remapInstructions(DenseMap<int, int> &SlotRemap):

   // Remap debug information that refers to stack slots.
   MachineModuleInfo::VariableDbgInfoMapTy &VMap = 
   for (MachineModuleInfo::VariableDbgInfoMapTy::iterator VI = VMap.begin(),
        VE = VMap.end(); VI != VE; ++VI) {
     const MDNode *Var = VI->first;
     if (!Var) continue;
     std::pair<unsigned, DebugLoc> &VP = VI->second;
     if (SlotRemap.count(VP.first)) {
       DEBUG(dbgs()<<"Remapping debug info for ["<<Var->getName()<<"].\n");
       VP.first = SlotRemap[VP.first];

Note that this iterates over all VariableDbgInfos of all functions 
(since it is a Machine*Module*Info), but it only checks if the frame 
index matches, not if Var is actually in the current MachineFunction.

This causes the StackColoring pass to change the frame index from 0 to 
27 in my simple small function due to some optimisation in a completely 
unrelated large function.

This doesn't seem right .. so either I am missing something here, or 
this loop is missing some code to check if the variables actually belong 
to the current MF. I don't really know how to do this check though..

(I have not been able to create a simple testcase that triggers this 
code though, and I cannot share the code on which it fails as it is not 

Kind regards,

More information about the llvm-dev mailing list