[PATCH] D135488: [codegen] Display stack layouts in console

Tue Nov 15 15:09:40 PST 2022

paulkirth added a comment.

In D135488#3928831 <https://reviews.llvm.org/D135488#3928831>, @dblaikie wrote:

> Any chance we could squirrel the info away (I assume there's a reason we can't compute the info where the warn-stack-size LLVM feature is implemented in PrologEpilogInserter.cpp) somewhere, and emit it as part of the frame-larger-than/warn-stack-size diagnostic?
>
> (also, we do already have an opt remark for stack frame size in general (in PrologEpilogInserter, very close to where warn-stack-size is implemented), so it seems OK to use the remark infrastructure for a more detailed stack report - but ideally if the point is to make frame-larger-than better, it'd be good to include the info in that diagnostic)

Originally, I had prototyped this to run when emitting `-Wframe-larger-than` diagnostics, however being able to dump the stack layout easily seems valuable on its own. The biggest advantage to delaying the pass is that we can print better diagnostics after the `LiveDebugValues` pass has a chance to run. The layout isn't affected, but we can print out more variable mappings by delaying the printing pass.

In D135488#3928851 <https://reviews.llvm.org/D135488#3928851>, @dblaikie wrote:

>> as a more general diagnostic output, like the other printing passes.
>
> As an aside: I don't think any "printing pass" is designed to be used beyond LLVM compiler engineers - they're implementation details of the compiler, even/much moreso than the optimization remarks infrastructure, which is user-surfaced/clang-flag-supported/passed through suitable APIs (rather than emitted raw to streams from the middle/backend). Optimization remarks are plumbed through the diagnostic infrastructure, can be suppressed/enabled, have file/line info at least some of the time, get all the clang diagnostic formatting infrastructure (eg: current work to have a SARIF output mode would be done up in clang, etc - and raw/direct output from LLVM wouldn't be captured/handled by that work, for instance), colouring, etc.

Thanks for the clarification. Those are good points, so thank you for the detailed answer.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135488