<div dir="ltr">I chatted with Jeremy Morse, Orlando, and Stephen Tozer at the dev meeting, and wanted to summarize the conversation for our benefit, and to share it with others. I aim to be brief, so I apologize if these notes aren't as helpful as they could be to folks who weren't present.<div><br></div><div>Three project ideas, by priority:</div><div>1. Address <a href="https://llvm.org/pr34136">https://llvm.org/pr34136</a>, improving quality of variable location info for variables in memory, by getting the frontend to pre-annotate assignments.</div><div>2. Prototype "stop points", or statement markers in the instruction stream. Use Dexter or other tools to measure potential improvements in stepping behavior, consider productionizing.</div><div>3. Move all debug info intrinsics out of the instruction stream by adding a new all-powerful instruction (maybe dbg_point, dbg_label?) that essentially multiplexes one llvm::Instruction into multiple debug instructions.</div><div>4. (bonus) Old idea, low-priority: Prototype a mode that models stop points as having side effects. Start the function by escaping all non-temporary local variables. Variable values should be accurate and writable at all statement start PCs.</div><div><br></div><div>Idea 1: Local variables in memory</div><div><br></div><div>Have clang emit dbg.value instructions directly after every assignment. We discussed the similarities of this idea to the idea of "Key Instructions" from Caroline Tice's thesis, but I can't claim this idea is totally faithful to it. For assignments to memory locations that are not local variables (*p = v, this->m = v), replace the local variable metadata argument with the value of the store destination, using ValueAsMetadata. Standard cleanup passes (instcombine, inliner?) should transform dbg.values with memory destinations that point into an alloca with the corresponding local variable for the alloca. This allows passes that delete stores other than mem2reg (DSE, Instcombine, GVN, anything using MemorySSA) to not worry about producing dbg.values because they already exist: the frontend has provided them. This was the fundamental reason why lowerDbgDeclare is called in Instcombine, so we can remove that, keep the dbg.declare instructions or something equivalent, and greatly expand the range over which the variable is known to live in stack memory. Variables which never participate in dead store elimination (hopefully many) are more likely to be entirely described by a memory location, and to not need a DWARF location list. They will be writable as well.</div><div><br></div><div>Idea 2: Stop points</div><div><br></div><div>This is an old idea: LLVM used to have stop point intrinsics before it had debug location instruction attachments. Given the new goals around profiling accuracy that we've declared for location information, perhaps we should reconsider the merits of the old design. A new intrinsic that functions similarly to dbg.value in that it produces no value, remains in the instruction stream, and is not removed by standard dead code elimination should be introduced. Perhaps dbg.stmt. This could be lowered down to power the .loc is_stmt bit in the DWARF line tables. We could also have a mode where the *only* information used to fill in the line tables comes from these instructions. Some data flow passes would be required to propagate the current location into blocks during codegen, similar to some of the existing debug value passes.</div><div><br></div><div>Idea 3: dbg_point</div><div><br>This is a representational change that is mostly meant to make LLVM more efficient. I don't have data, but we believe that runs of dbg.value instructions slow down passes because they must be iterated over during optimization. We also believe that they are memory inefficient. A new representation would address that by allowing us to coalesce multiple logically distinct dbg.value operations into one llvm::Instruction. This instruction could be extended to contain all types of debug info instuctions: dbg.label, dbg.value, dbg.declare, dbg.stmt, or anything else. Having just watched the MLIR tutorial, it reminds me of MLIR regions.</div><div><br></div><div>Idea 4: Not much to say</div><div><br></div><div>---</div><div><br></div><div>That's all, I'm sure there was more that I missed, and these ideas are perhaps a bit hare-brained still, but maybe the wider community will have some input.</div><div><br></div><div>Thanks,</div><div>Reid</div><div><br></div></div>