GitHub PushEvent at 2014-06-01 03:46:45
Repository: llvm-project-submodule
Actor: chapuni
Payload: {"shas":[["f34bcccc7b151de76c839180caccfcfe3f479dd8","05f726f834638679f776bde9b9fcd7e9d7242de5@gmail.com","DebugInfo: Assert that DbgVariables have associated DIEs\n\nThis was previously committed in r209680 and reverted in r209683 after\nit caused sanitizer builds to crash.\n\nThe issue seems to be that the DebugLoc associated with dbg.value IR\nintrinsics isn't necessarily accurate. Instead, we duplicate the\nDIVariables and add an InlinedAt field to them to record their\nlocation.\n\nWe were using this InlinedAt field to compute the LexicalScope for the\nvariable, but not using it in the abstract DbgVariable construction and\nmapping. This resulted in a formal parameter to the current concrete\nfunction, correctly having no InlinedAt information, but incorrectly\nhaving a DebugLoc that described an inlined location within the\nfunction... thus an abstract DbgVariable was created for the variable,\nbut its DIE was never constructed (since the LexicalScope had no such\nvariable). This DbgVariable was silently ignored (by testing for a\nnon-null DIE on the abstract DbgVariable).\n\nSo, fix this by using the right scoping information when constructing\nabstract DbgVariables.\n\nIn the long run, I suspect we want to undo the work that added this\nsecond kind of location tracking and fix the places where the DebugLoc\npropagation on the dbg.value intrinsic fails. This will shrink debug\ninfo (by not duplicating DIVariables), make it more efficient (by not\nhaving to construct new DIVariable metadata nodes to try to map back to\na single variable), and benefit all instructions.\n\nBut perhaps there are insurmountable issues with DebugLoc quality that\nI'm unaware of... I just don't know how we can't /just keep the DebugLoc\nfrom the dbg.declare to the dbg.values and never get this wrong/.\n\nSome history context:\n\nhttp://llvm.org/viewvc/llvm-project?view=revision&revision=135629\nhttp://llvm.org/viewvc/llvm-project?view=revision&revision=137253","David Blaikie",true]],"size":1,"ref":"refs/heads/master","head":"f34bcccc7b151de76c839180caccfcfe3f479dd8"}