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

Chuanqi Xu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 6 19:16:12 PDT 2021


ChuanqiXu added a comment.

In D99179#2672682 <https://reviews.llvm.org/D99179#2672682>, @dblaikie wrote:

> 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.

Thanks for reviewing! I would try to enhance the test case.

> 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.

>From my perspective, it looks like the callback to frontend wouldn't work since clang frontend is worked on AST instead of LLVM IR. If we want a callback to clang to handle this, we need to preserve the frontend information like AST to the LLVM IR. This seems to be a hardest method.

> (fundamental design discussion/decision might be worth a broader design discussion on llvm-dev with a bunch of debug info folks - not sure)

I would try to discuss it in llvm-dev. It seems like there two things we need to discuss:

- Is it ok to construct debug information in LLVM Passes? If yes, we could construct corresponding interface to IR module instead of coroutine module.
- If no, how can we solve these problems? One thought I had is to emit debug type information for LLVM types in the frontend. But I am not sure if it would obstacle the optimizations.


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

https://reviews.llvm.org/D99179



More information about the llvm-commits mailing list