[PATCH] D80052: [docs] Sketch outline for HowToUpdateDebugInfo.rst

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro added inline comments.


================
Comment at: llvm/docs/HowToUpdateDebugInfo.rst:21
+
+IR-level transformations
+========================
----------------
vsk wrote:
> djtodoro wrote:
> > A TODO on changing DIMeatadata (such as introducing a DIFlag etc) by describing bitcode backward compatibility etc. ?
> I think we should spin up a separate document to describe how to hack on llvm's debug info facilities/representation. That way, we can keep this doc focused on what llvm pass authors need to know.
Having the `A Guide for LLVM Pass Authors` makes sense to me! Thanks!


================
Comment at: llvm/docs/HowToUpdateDebugInfo.rst:232
+   be precise enough), moving the test to its own file is preferred.
+
+MIR-level transformations
----------------
vsk wrote:
> jmorse wrote:
> > djtodoro wrote:
> > > vsk wrote:
> > > > aprantl wrote:
> > > > > Do we want to add a section on SelectionDAG & GlobalISel, DAGCombine, etc?
> > > > The info about MIR should generally carry over to GIsel. This probably does need a separate section for SelectionDAG, but I'm not sure how to structure that, so I'll leave it as TODO as well.
> > > I guess we can add TODOs for the sections on VirtRegRewriter/LiveDebugVariables; LiveDebugValues; AsmPrinter(DwarfDebug;DwarfExpression); as well.
> > My feeling is that the debug specific passes are best documented in SourceLevelDebugging.rst instead -- with this document focused on how optimisation writers should use LLVM APIs to preserve debug info in their passes.
> > 
> > The isel passes kind of fall into both those categories -- there's debug updating occurring, but lots of unrelated implementation details too.
> +1 to @jmorse's comment here.
Makes sense to me, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80052