thegameg added a comment.

In D135488#4024713 <https://reviews.llvm.org/D135488#4024713>, @paulkirth wrote:

> @arsenm @thegameg @nickdesaulniers @dblaikie @phosek Can we reach a consensus 
> here on how to output this kind of information? I feel like I've been told to 
> move towards remarks as the output method, but that the current diagnostic 
> that tries to lay out the stack visually isn't a good fit since remarks are 
> also serialized ... I'm not all that convinced that providing output other 
> than a visual layout for this information is all that useful in this 
> particular case, but I don't have an issue with supporting it either.  I 
> think this is especially true, since memory layouts are tricky to reason 
> about.
>
> For that reason, I'm pretty sure we want to actually //show// the user the 
> layout directly in the diagnostic. My concern is that if we change the output 
> to better fit within the remarks infrastructure, we lose an effective way to 
> show users what's happening. If we take away the visual representation, then 
> we'll end up needing to run a separate tool and post-process the serialized 
> output to have a user make any real sense of how things are layed out. That 
> seems like a pretty bad user experience, so I'd much rather find a way to 
> have the compiler emit this information directly.
>
> Does anyone have thoughts here on how to move forward?

I think remarks are the right way to go with this. They provide a pretty 
flexible way to emit both strings (for formatting and visual representations) 
and machine-readable data through `ore::NV` entries. We just need to find a 
consensus on how it looks like in both the command-line and the serialized mode.



================
Comment at: llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp:178
+
+    emitHeaderRemark(MF);
+
----------------
paulkirth wrote:
> thegameg wrote:
> > From what I can see, you've focused on the `-Rpass` output using 
> > diagnostics and tried to emit a pretty-printed version for that on the 
> > command line.
> > 
> > We use remarks through their serialized version as well, through 
> > `-fsave-optimization-record` which will emit a YAML file that can be used 
> > in scripts and other post-processing tools.
> > 
> > I think this should be something in between where it looks user-friendly on 
> > the command-line but also easy to post-process.
> > 
> > One way would be to do something similar to [[ 
> > https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Utils/MemoryOpRemark.cpp
> >  | the memory op remarks ]], which are used here: [[ 
> > https://github.com/llvm/llvm-project/blob/main/llvm/test/Transforms/Util/trivial-auto-var-init-call.ll
> >  | llvm/test/Transforms/Util/trivial-auto-var-init-call.ll ]].
> > 
> > I could see something where you emit a remark for each slot (+ location), 
> > with `ore::NV` used for each piece of information that is useful, something 
> > like:
> > 
> > ```
> > ORE << MachineOptimizationRemarkAnalysis(...) << "Stack slot: offset: " << 
> > ore::NV("Offset", D.offset)
> >                                                                             
> >         << "type: " << ore::NV("Type", type)
> > [...]
> > ```
> > 
> > and could generate something like:
> > 
> > ```
> >  --- !Analysis
> >  Pass:            stack-frame-layout
> >  Name:            StackSlot
> >  Function:        stackSizeWarning
> >  Args:
> >    - String:          'Stack slot: offset: '
> >    - Offset:         '[SP-8]'
> >    - String:          ', type: '
> >    - Type:            'spill'
> >    - String:          ', align: '
> >    - Align:           '16'
> >    - String:          ', size: '
> >    - Align:           '8'
> >  ...
> > ```
> > 
> > which would look like this on the command line:
> > 
> > ```
> > remark: Stack slot: offset: [SP-8], type: spill, align: 16, size 8
> > ```
> > 
> Thanks for the suggestion. While I understand the desire to make the output 
> more machine readable, I don't think this is a good place to do so. Layouts 
> are hard to reason about and there's actually a fairly decent way we can 
> display this to users and convey exactly where things are. The entire point 
> of this patch was to give a somewhat visual representation to how the stack 
> is layed out, and help debug stack layout issues. It's one of the reasons I 
> didn't originally do this with remarks, but there's been a fair amount of 
> discussion to this point already w/in this patch. 
> 
> If this isn't a good fit for remarks with the current format, then I'm kind 
> of stuck on how to satisfy the various requirements on how to output and 
> display this kind of information...
> 
> 
> 
I don't see a huge difference between:

```
remark: Offset            Align     Size
remark: [SP-8]      Spill 16        8
remark: [SP-16]     Spill 8         8
remark: [SP-24]     Spill 16        8
```

and

```
remark: Stack slot: offset: [SP-8], type: spill, align: 16, size 8
remark: Stack slot: offset: [SP-16], type: spill, align: 8, size 8
remark: Stack slot: offset: [SP-24], type: spill, align: 16, size 8
```

If you think this is what makes it really useful, we also support multi-line 
remarks (see [[ 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/Scalar/LowerMatrixIntrinsics.cpp
 | LowerMatrixIntrinsics.cpp ]], and you can still provide precise 
`ore::NV`-like entries. In that case you should probably emit one big 
`MachineOptimizationRemarkAnalysis` with `[SP-8]`, `spill`, `16`, and `8` as 
`ore::NV` entries, and the rest as a strings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135488

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to