[LLVMdev] StackColoring remaps debug info from unrelated functions
Stefan Hepp
stefan at stefant.org
Sun Sep 29 13:40:12 PDT 2013
Hi,
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 =
MMI->getVariableDbgInfo();
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];
FixedDbg++;
}
}
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
open..)
Kind regards,
Stefan
More information about the llvm-dev
mailing list