[PATCH] D99179: [RFC] [Coroutines] Enable printing coroutine frame in debugger if program is compiled with -g

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

Testing looks a bit better - could probably be more comprehensive.

General architecture of the change: Yeah, I dunno about creating new structures and things (& corresponding debug info) during optimizations, bit unfortunate/not something we've done before - but I don't know of much better, given my cursory understanding of the  current architecture & lowering of the coroutines this seems understandable if unfortunate.

Happy for @Aprantl to continue with review for the broader design, but I'll keep reading & chime in if I have further thoughts.

Perhaps if restructuring the passes is not practical - maybe the pass could be parameterized by the frontend that's creating the pass pipeline? insert some kind of callback... hmm, nope, that doesn't work because you might -disable-llvm-optzns to get LLVM IR out from clang then use llc (or disable frontend optimizations in an LTO build, etc) - yeah, not sure.



================
Comment at: llvm/test/Transforms/Coroutines/coro-debug-coro-frame.ll:16
+; CHECK: ![[RAMP:[0-9]+]] = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov"
+; CHECK: ![[CORO_FRAME]] = !DILocalVariable(name: "__coro_frame", scope: !{{[0-9]+}}, file: ![[FILE]], line: {{[0-9]+}}, type: ![[FRAME_TYPE:[0-9]+]])
+; CHECK: ![[FRAME_TYPE]] = !DICompositeType(tag: DW_TAG_structure_type, name: "__coro_frame_ty", {{.*}}elements: ![[ELEMENTS:[0-9]+]]
----------------
Probably worth checking the scope and line - since those are specified by the code being added in this patch (eg: if the patch did have a bug - passing the wrong line or scope, the test would still pass) - similarly for other fields in other records.


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

https://reviews.llvm.org/D99179