[PATCH] D144792: [DebugInfo][Docs] Remove `dbg.addr` from docs

[J. Ryan Stinnett via Phabricator via llvm-commits]

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

In D144792#4154663 <https://reviews.llvm.org/D144792#4154663>, @Orlando wrote:

> I wonder if it's worth leaving a dbg.addr section in here as a migration guide for front ends that use it (or perhaps a release note would be sufficient - we should probably include a release note either way).

I wasn't sure what the common practice around migration docs was... I tried looking around at how past feature removals were handled, and they all seemed to remove all docs as if the feature never existed, so that's what I went with here. I am not sure whether there's an actual policy, or if everyone's just following what the last person did... If someone would prefer migration docs, I can of course add them. It's somewhat unclear how many frontends (if any) adopted `dbg.addr` vs. following what Clang does (by not using it).

For the release note, that's a good suggestion, I will add a note about this.

> Additionally IMO it could be worth writing up another discourse post with a title that conveys the intention to remove dbg.addr to ensure no one feels caught out, linking to the existing discourse discussion. YMMV.

Ah yes, seems reasonable, I created another thread: https://discourse.llvm.org/t/dbg-addr-intrinsic-slated-for-removal/68781



================
Comment at: llvm/docs/SourceLevelDebugging.rst:203
     ; The address of i is buffer+64.
-    call void @llvm.dbg.addr(metadata [256 x i8]* %buffer, metadata !3,
-                             metadata !DIExpression(DW_OP_plus, 64)), !dbg !4
+    call void @llvm.dbg.declare(metadata [256 x i8]* %buffer, metadata !3,
+                               metadata !DIExpression(DW_OP_plus, 64)), !dbg !4
----------------
Orlando wrote:
> I guess we should update the docs to use opaque pointers in these examples (e.g. `metadata ptr %buffer`) but that is probably something for a seperate patch, since there are parts that need updating other than the bits you're touching here.
Right, probably best for a separate patch. There may be over conventions that need updating here (e.g. `undef` usage) as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144792