[PATCH] D57694: [DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEs

Mon Mar 25 04:21:17 PDT 2019

jmorse marked an inline comment as done.
jmorse added a comment.

In D57694#1440571 <https://reviews.llvm.org/D57694#1440571>, @srhines wrote:

> This patch appears to generate non-reproducible builds in some cases. I can craft a more minimal test case, but the following link (https://godbolt.org/z/sWucUZ) is what I have been using. If I run Clang multiple times, the output eventually swaps the order of some undef DEBUG_VALUE's. I am just passing "-O1 -g" with that .ii file. It isn't obvious to me yet what is causing this to be unordered/non-deterministic.

Curses; you're correct, and Roman seems to have pinned down where it comes from. I'll generate a patch shortly, many thanks for reducing and reporting this!

================
Comment at: llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:1351
+  // Try to fixup any remaining dangling debug info -- and drop it if we can't.
+  for (auto &Pair : DanglingDebugInfoMap)
+    for (auto &DDI : Pair.getSecond())
----------------
lebedev.ri wrote:
> ```
>   /// Keeps track of dbg_values for which we have not yet seen the referent.
>   /// We defer handling these until we do see it.
>   DenseMap<const Value*, DanglingDebugInfoVector> DanglingDebugInfoMap;
> ```
> I don't think `DenseMap` iteration order is guaranteed, unlike `std::map`?
> 
I believe you're right -- and the order in which salvageUnresolvedDbgValue is called can be preserved in a vector further into SelectionDAG.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57694/new/

https://reviews.llvm.org/D57694