[codegen] Add StackFrameLayoutAnalysisPass

[paulkirth]

Summary

Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.

This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.

The new behavior can be used by adding -Rpass-analysis=stack-frame-layout
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.

Fixes: #58168

[myhsu]

llvm/lib/CodeGen/StackFramePrinterPass.cpp

79 ↗

(On Diff #470989)

const SlotData &? If this is true please also update the call site (e.g. line 143)

138 ↗

(On Diff #470989)

nit: use llvm::sort so that we can simply write llvm::sort(SlotInfo, <comparer>)

llvm/test/CodeGen/ARM/stack-frame-printer.ll

221 ↗

(On Diff #470989)

nit: is it possible to clean up some of the irrelevant strings like the producer and directory fields?

[paulkirth]

Thanks for the feedback. Those are good catches. I'll send out a patch cleaning those up.

[paulkirth]

Address comments

• fix brancing style
• update parameters to use const
• use llvm::sort in place of std::sort
• remove path strings from debug info in test files

[nickdesaulniers]

Can we add a Note diagnostic when we emit a -Wframe-larger-than= that alludes to re-running with -mllvm -print-stack-frame to get additional info?

We should update the release notes of clang to mention this feature, too.

[arsenm]

In D135488#3928557, @nickdesaulniers wrote:

Can we add a Note diagnostic when we emit a -Wframe-larger-than= that alludes to re-running with -mllvm -print-stack-frame to get additional info?

We should update the release notes of clang to mention this feature, too.

I don't think we should be pointing users to -mllvm flags. Plus, I don't really think random dbgs() printing is going to interact correctly with other diagnostics

llvm/lib/CodeGen/StackFramePrinterPass.cpp

120–122 ↗

(On Diff #471235)

Check MFI.isDead instead?

[nickdesaulniers]

In D135488#3928559, @arsenm wrote:

In D135488#3928557, @nickdesaulniers wrote:

Can we add a Note diagnostic when we emit a -Wframe-larger-than= that alludes to re-running with -mllvm -print-stack-frame to get additional info?

We should update the release notes of clang to mention this feature, too.

I don't think we should be pointing users to -mllvm flags. Plus, I don't really think random dbgs() printing is going to interact correctly with other diagnostics

Then how will users know about super cool things? We could create a new front end flag for this -mllvm flag, a la https://reviews.llvm.org/D131986.

[nickdesaulniers]

In D135488#3928567, @nickdesaulniers wrote:

In D135488#3928559, @arsenm wrote:

In D135488#3928557, @nickdesaulniers wrote:

Can we add a Note diagnostic when we emit a -Wframe-larger-than= that alludes to re-running with -mllvm -print-stack-frame to get additional info?

We should update the release notes of clang to mention this feature, too.

I don't think we should be pointing users to -mllvm flags. Plus, I don't really think random dbgs() printing is going to interact correctly with other diagnostics

Then how will users know about super cool things? We could create a new front end flag for this -mllvm flag, a la https://reviews.llvm.org/D131986.

Sorry, bad example; that example is adding IR Function attributes, not setting -mllvm flags (which tend to get dropped during LTO unless re-passed to the linker), but there is a -mllvm flag for that. https://reviews.llvm.org/D127988

Regardless, we _could_ wire up a frontend flag for more info, I think. Not sure we have precedence for that, but it would be really really helpful to folks presented with -Wframe-larger-than= warnings.

[arsenm]

In D135488#3928567, @nickdesaulniers wrote:

In D135488#3928559, @arsenm wrote:

In D135488#3928557, @nickdesaulniers wrote:

Can we add a Note diagnostic when we emit a -Wframe-larger-than= that alludes to re-running with -mllvm -print-stack-frame to get additional info?

We should update the release notes of clang to mention this feature, too.

I don't think we should be pointing users to -mllvm flags. Plus, I don't really think random dbgs() printing is going to interact correctly with other diagnostics

Then how will users know about super cool things? We could create a new front end flag for this -mllvm flag, a la https://reviews.llvm.org/D131986.

I'd be a bit more comfortable routing this through the backend remarks infrastructure, although it's a lot bigger than everything else currently reported there

[paulkirth]

Thanks for the feedback! I have a few questions I'm hoping you can answer.

In D135488#3928559, @arsenm wrote:

I don't think we should be pointing users to -mllvm flags. Plus, I don't really think random dbgs() printing is going to interact correctly with other diagnostics

I modeled this pass off of the MachineFunctionPrinterPass, does that mean it it should also use a different stream? This seems to be a fairly common pattern, so should we be filing bugs and tracking work in this area?

In D135488#3928580, @arsenm wrote:

I'd be a bit more comfortable routing this through the backend remarks infrastructure, although it's a lot bigger than everything else currently reported there

I'm not sure that this diagnostic belongs in optimization remarks, though. It isn't describing any of the decision making that went into the stack layout, which is what I think most remarks typically describe. I'm basing that on https://clang.llvm.org/docs/UsersManual.html#options-to-emit-optimization-reports. Is my interpretation of that too narrow?

Also, is there something special about the remarks output that makes it better? Is the setup/initialization more careful than for the other streams? I'd like to understand the trade-off a bit better. Our documentation makes it seem as though its geared towards compiler engineers, where I view this as a more general diagnostic output, like the other printing passes.

llvm/lib/CodeGen/StackFramePrinterPass.cpp

120–122 ↗

(On Diff #471235)

Oh, good suggestion. That check bothered me, but I missed that API. I'll update this patch to reflect your suggestion.

[dblaikie]

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)

[dblaikie]

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.

[paulkirth]

In 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, @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.

[dblaikie]

In D135488#3928963, @paulkirth wrote:

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

Fair enough - could the warn-stack-size warning be moved to there, then, and then the information included in the warning? It could have both a warning and remark form, so folks could use the remark form when they just want all the reports or don't want the reports phrased as a problem, but as an informational message? (though this may or may not be worth it - I guess people can turn on the warning, lower the threshold, and specifically make this warning a non-error, which amounts to roughly the same thing as a remark)

[paulkirth]

Rebase and address comments

• Replace magic comparison with MFI.isDeadIbjectIndex()
• Small code improvement by using a constructor w/ emplace_back

[paulkirth]

In D135488#3928975, @dblaikie wrote:

Fair enough - could the warn-stack-size warning be moved to there, then, and then the information included in the warning? It could have both a warning and remark form, so folks could use the remark form when they just want all the reports or don't want the reports phrased as a problem, but as an informational message? (though this may or may not be worth it - I guess people can turn on the warning, lower the threshold, and specifically make this warning a non-error, which amounts to roughly the same thing as a remark)

I guess it could be moved, but I'm not sure it makes the most sense. PrologEpilogueInserter is also already emitting the optimization remarks for stack size, so IMO it makes sense to keep them together, since that's the place where that information is determined. But there is no technical reason why we couldn't move it later, since all the information to do the check is readily available.

Another point to consider is that we already have several ways to expose stack sizes to users. -Wframe-larger-than gives warnings when a threshold is exceeded, but we also provide -fstack-size-section, and -fstack-usage which output information about every function in the module. And, as mentioned earlier, there is an optimization remark for stack sizes too.

Regardless, I'll take a look and see how easy it will be to expose this through the remarks infrastructure, since that seems to be a generally good idea here.

[nickdesaulniers]

In D135488#3928831, @dblaikie wrote:

Any chance we could ... emit it as part of the frame-larger-than/warn-stack-size diagnostic?

This pass prints a TON of (helpful) information...we have a lot of -Wframe-larger-than= instances triggered in our codebase...I think having this on by default would blow our logs significantly. That's why it might be nice to have a Note suggest a flag (default off) for more info on a case by case basis.

[paulkirth]

As a quick test, I hacked the printer pass to generate an output string, and passed that into the remarks emitter. From opt or llc things look as expected. There's some additional output, but its limited.

I see a more serious issue when using it from Clang, as the output is truncated , as in it only printed up to the first stack slot in my test. Its also all bold, which isn't great. I have a feeling that my shortcut is the root cause of the truncation, but I haven't tracked down the issue exactly.

Do any other remarks output complex data like this? From what I can see they tend to be fairly short…

I also thought about printing each line as a remark, but that seems to get noisy pretty fast, since each line would have the remark <file location> tag plus an [-Rpass-analysis=stackframe-printer] at the end.

Example truncated output (each function should have several lines w/ offset from SP, alignment, and size):

$ clang -O1 -Rpass-analysis=stackframe-printer llvm/test/CodeGen/X86/stack-frame-printer.ll -c -o /dev/null -mllvm -print-stack-frame                        

remark: <unknown>:0:0: 
# Stack Layout: stackSizeWarning
 [-Rpass-analysis=stackframe-printer]
remark: <unknown>:0:0: 
# Stack Layout: cleanup_array
Offset            Align     Size      
[SP-8]      Spill 16        8         

 [-Rpass-analysis=stackframe-printer]
remark: <unknown>:0:0: 
# Stack Layout: cleanup_result
Offset            Align     Size      
[SP-8]      Spill 16        8         

 [-Rpass-analysis=stackframe-printer]
remark: <unknown>:0:0: 
# Stack Layout: do_work
Offset            Align     Size      
[SP-8]      Spill 16        8         

 [-Rpass-analysis=stackframe-printer]
remark: <unknown>:0:0: 
# Stack Layout: gen_array
Offset            Align     Size      
[SP-8]      Spill 16        8         

 [-Rpass-analysis=stackframe-printer]
remark: <unknown>:0:0: 
# Stack Layout: caller
Offset            Align     Size      
[SP-8]      Spill 16        8         

 [-Rpass-analysis=stackframe-printer]

Output from llc (which looks more or less as expected):

$ llc -mcpu=corei7 -O1 -print-stack-frame -pass-remarks-analysis=stackframe-printer < llvm/test/CodeGen/X86/stack-frame-printer.ll 2>&1 >/dev/null

remark: <unknown>:0:0: 
# Stack Layout: stackSizeWarning
Offset            Align     Size      
[SP-88]           16        80        
    buffer @ frame-diags.c:30
[SP-168]          16        80        
    buffer2 @ frame-diags.c:33


remark: <unknown>:0:0: 
# Stack Layout: cleanup_array
Offset            Align     Size      
[SP-8]      Spill 16        8         
[SP-16]           8         8         
    a @ dot.c:13


remark: <unknown>:0:0: 
# Stack Layout: cleanup_result
Offset            Align     Size      
[SP-8]      Spill 16        8         
[SP-16]           8         8         
    res @ dot.c:21


remark: <unknown>:0:0: 
# Stack Layout: do_work
Offset            Align     Size      
[SP-8]      Spill 16        8         
[SP-12]           4         4         
    i @ dot.c:55
[SP-24]           8         8         
    AB @ dot.c:38
[SP-28]           4         4         
    len @ dot.c:37
[SP-32]           4         4         
[SP-40]           8         8         
    out @ dot.c:32
[SP-48]           8         8         
    B @ dot.c:32
[SP-56]           8         8         
    A @ dot.c:32
[SP-60]           4         4         
    sum @ dot.c:54


remark: <unknown>:0:0: 
# Stack Layout: gen_array
Offset            Align     Size      
[SP-8]      Spill 16        8         
[SP-12]           4         4         
    i @ dot.c:69
[SP-16]           4         4         
    size @ dot.c:62
[SP-24]           8         8         
    res @ dot.c:65
[SP-32]           8         8         


remark: <unknown>:0:0: 
# Stack Layout: caller
Offset            Align     Size      
[SP-8]      Spill 16        8         
[SP-12]           4         4         
    ret @ dot.c:81
[SP-16]           4         4         
[SP-24]           8         8         
    res @ dot.c:80
[SP-32]           8         8         
    B @ dot.c:79
[SP-40]           8         8         
    A @ dot.c:78
[SP-44]           4         4         
    err @ dot.c:83
[SP-48]           4         4         
    size @ dot.c:77

Are there any thoughts about how to make this work more nicely w/ optimization remarks from Clang?

[arsenm]

The kernel resource remarks added in 67357739c6d36a61972c1fc0e829e35cb5375279 are probably the current heaviest remarks. I believe there were some changes to newline handling for it

[dblaikie]

This pass prints a TON of (helpful) information...we have a lot of -Wframe-larger-than= instances triggered in our codebase...I think having this on by default would blow our logs significantly. That's why it might be nice to have a Note suggest a flag (default off) for more info on a case by case basis.

I'm not sure we'd need/want to optimize a diagnostic experience for a codebase that's got a lot of latent warnings. If people have lots of existing warnings they should probably turn the warning off (in those instances, at least) & I think saying "this function has a frame that's too big" without any info is pretty hard to act on, so it doesn't seem totally outside the realm of good diagnostics for this particular diagnostic to print a lot of info to help a user act on it/fix the issue when they get it. If most of the time you see this warning and want to fix it, you had to run your build again with an extra flag - I'd say that was a bad diagnostic experience, we should give them enough info the first time around.

If most of the time you don't need this info - yeah, that's something we should figure out, how to provide the right amount of info to be actionable, but in this case I suspect more-often-than-not you want some kind of report/breakdown. If it's a case of not having a way to make it more targeted/actionable and we just have two options ("too terse" and "too verbose") fairly evenly split (it's not clear that most of the time one or the other is the right answer) - I guess two different warning flags or some kind of modifier flag could be suitable. I guess we have that for template recursion things, maybe? Where you can ask if you want the full expansion, but by default we give you a summarized one, skipping expansions we don't think are relevant (I might be misremembering).

[arsenm]

In D135488#3929537, @arsenm wrote:

The kernel resource remarks added in 67357739c6d36a61972c1fc0e829e35cb5375279 are probably the current heaviest remarks. I believe there were some changes to newline handling for it

D127923 is the patch for the line handling

[paulkirth]

Sorry, it took me a while to circle back to this.

In D135488#3931603, @dblaikie wrote:

I'm not sure we'd need/want to optimize a diagnostic experience for a codebase that's got a lot of latent warnings. If people have lots of existing warnings they should probably turn the warning off (in those instances, at least) & I think saying "this function has a frame that's too big" without any info is pretty hard to act on, so it doesn't seem totally outside the realm of good diagnostics for this particular diagnostic to print a lot of info to help a user act on it/fix the issue when they get it. If most of the time you see this warning and want to fix it, you had to run your build again with an extra flag - I'd say that was a bad diagnostic experience, we should give them enough info the first time around.

On the topic of how frequent warnings should be, it's important to keep in mind that a function with a large stack frame will generate a diagnostic in every caller who has inlined that function. So even if you were warning free in the last build a single function using too much stack could generate a lot of diagnostics.

If most of the time you don't need this info - yeah, that's something we should figure out, how to provide the right amount of info to be actionable, but in this case I suspect more-often-than-not you want some kind of report/breakdown. If it's a case of not having a way to make it more targeted/actionable and we just have two options ("too terse" and "too verbose") fairly evenly split (it's not clear that most of the time one or the other is the right answer) - I guess two different warning flags or some kind of modifier flag could be suitable. I guess we have that for template recursion things, maybe? Where you can ask if you want the full expansion, but by default we give you a summarized one, skipping expansions we don't think are relevant (I might be misremembering).

While I agree that running the build again isn't ideal, I don't' see a good way to balance the need for clang to report concise errors with the need for more information in this case. Reading D127923, I think it's clear that many of clang's maintainers would like to keep diagnostics concise if possible. I should also note that we already give some minimal context to -Wframe-larger-than diagnostics by printing the breakdown of the stack usage between spills, program variables, and the UnSafeStack.

I think the right approach in this case is to allow developers to opt into the behavior when needed, so your suggestion of gating it behind a flag seems like a good way to express that. I also think the diagnostic is useful enough on its own to warrant use outside of -Wframe-larger-than, despite being very useful when triaging those type of warnings. I guess that means I should take a harder look at plumbing this through the remarks infrastructure, even if I don't love the output.

[paulkirth]

Refactor implementation to use remarks infrastructure

• Simplify interfaces
• Add tests in Clang
• Update pipeline tests
• Rename pass and test files

[paulkirth]

Add missing pipline test updates for PowerPC and AMDGPU

[thegameg]

This is great! Any chance we can use MachineFrameInfo::StackProtectorIdx to annotate the slot that is reserved for the stack protector?

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

85

I don't think this should ever be null.

[paulkirth]

Avoid problems with path separators on windows, and ignore path prefix in diagnostic

[paulkirth]

@thegameg Maybe? It seems straightforward, but I'll need take a look. If it's easy(which I think it willbe), I'll try to update this patch, if it's more complex, I'll probably do a separate patch to add that feature.

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

85

Ah, good point. I always default to nullptr checks, but in this case that should be impossible. thanks for pointing that out.

[paulkirth]

Remove unnecesary null pointer check.

[paulkirth]

Rebase

[paulkirth]

Identify the stack protector in output

[thegameg]

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

93

Why are we emitting the function name? In the serialized remarks (-fsave-optimization-record) it comes in the Function field, and in the diagnostics (-Rpass*) it uses debug info to show the source around it.

if it's for testing only, you can test using the serialized remarks with YAML.

125

We usually use identifiers for remark names, so here StackLayout instead of Stack Layout.

179

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 the memory op remarks, which are used here: 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

[paulkirth]

@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?

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

93

I followed the example from since it was brought up earlier. https://github.com/llvm/llvm-project/blob/f40d25dd8d3ad7bcfa8f5e8f74f245ab1a7675df/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp#L1223

Also, there is not guarantee you have debug info when you run this, right? Also you won't get a function name in the console if you run this over IR, even when debug information is included w/in the IR.

I see remark: <unknown>:0:0: ... when running any of the IR tests.

125

hmm, I was following the example in https://github.com/llvm/llvm-project/blob/f40d25dd8d3ad7bcfa8f5e8f74f245ab1a7675df/llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp#L1223, but it looks like I may have swapped them. I'll take a closer look at the output and fix accordingly (here and elsewhere).

179

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

[thegameg]

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

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

179

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

[paulkirth]

I think ideally I'd like to surface something like this:

A:

or

B:

The first image uses stdout, and the second uses remarks, but prints everything from the function as a single string. This provides some output that is pretty easy for a human to consume, and wouldn't be too hard to parse for an external tool. It isn't as nice from a machine readable perspective as something like JSON or YAML.

The big issue that I'm seeing is that printing multiple remarks ends up printing the path to the source file given as provided on the commandline. If that's from a build system, it will likely be a full path and a user is likely going to have a similar issue. The following examples are, IMO, much harder to make sense of. I see similar issues, even if I make my terminal full screen width.

C:

or (if I format things as suggested)

D:

I'm a bit stumped on how to make this work nicely w/ remarks and provide good support for both the CLI and YAML...

[thegameg]

I don't think I understand why we can't achieve B with remarks? In C and D you generate one remark for each line, can't we generate a single multi-line remark instead?

[paulkirth]

Rebase.

• Switch to multi-line remarks
• Update tests

[paulkirth]

Add test for YAML output

[thegameg]

This looks great, thanks for updating this! A few more comments inline.

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

56

66

111

Is this still worth being a separate function?

129

Unused?

180

Can you add a comment on what ValOffset is?

[paulkirth]

@thegameg I think I finally understood what you meant re: multi-line remarks. Sorry for the back/forth on that, it just didn't click for me until you commented on the screenshot.

BTW, is there a way to nest some of the items? Ideally we'd be able to have a Slot in the YAML that contains all the various data, similar to how DebugLoc is a more complex object with fields for File, Line, and Column. That way we could group all the data for each slot including variable locations.

I know how that would look in YAML, but I'm unaware of how we'd do that with the existing remarks interfaces... or if doing so would massively change the CLI output. any pointers here?

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

56

Good catch! TY

111

yeah, probably not

129

Yeah, looks like I forgot to remove this. Thanks

[thegameg]

In D135488#4044437, @paulkirth wrote:

BTW, is there a way to nest some of the items? Ideally we'd be able to have a Slot in the YAML that contains all the various data, similar to how DebugLoc is a more complex object with fields for File, Line, and Column. That way we could group all the data for each slot including variable locations.

I know how that would look in YAML, but I'm unaware of how we'd do that with the existing remarks interfaces... or if doing so would massively change the CLI output. any pointers here?

Unfortunately no, there is no easy way to do that right now, but I agree it would be nice. The Args seem easy enough to process that I wouldn't bother trying to group them. optrecord.py (and libRemarks) will handle it in the right order so the users can easily work with it.

[paulkirth]

Address comments.

• document what ValOffset is used for
• remove dead code
• fix typo

[thegameg]

Looks great with the leftover minor changes, feel free to land this, thanks! I'll give this a try internally and provide feedback if any.

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

56

I also suggested Invalid instead of Error but it's up to you.

111

Looks like this stayed around unused

[paulkirth]

• Actually remove dead code
• Update pass description to be more accurate
• fix typo
• update enum member name

[paulkirth]

Update clang test for windows file separators.

[paulkirth]

Add target triple to all RUN lines.

Seems like the layout is the same on 64-bit windows, but for some reason
clang.exe chooses i386 unless the triple is set. So just set the triple
uniformly, and avoid any potential problems.

Also add a REQUIRES line to the test, since these need an x86_64 target

[paulkirth]

Make YAML tests less brittle.

[nickdesaulniers]

It would be really nice if we could limit this to a specific function somehow.

Quick feedback from giving Diff 488727 a spin on the Linux kernel:

via ARCH=arm make LLVM=1 -j128 -s allyesconfig all I found:

  CC      drivers/net/ethernet/mellanox/mlx5/core/en_main.o
drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3597:12: error: stack frame size (1256) exceeds limit (1024) in 'mlx5e_setup_tc' [-Werror,-Wframe-larger-than]
static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type type,
           ^

When I rebuild with:

ARCH=arm make LLVM=1 -j128 drivers/net/ethernet/mellanox/mlx5/core/en_main.o KCFLAGS=-Rpass-analysis=stack-frame-layout

I get a printout of the stack usage of every function in this TU. That's 1929 lines of text output...I only care about mlx5e_setup_tc. Is there a way to limit that?

Filtering through the logs though, I do see:

drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3599:1: remark: 
Function: mlx5e_setup_tc
...
Offset: [SP-400], Type: Variable, Align: 8, Size: 352
Offset: [SP-752], Type: Variable, Align: 8, Size: 352
Offset: [SP-1088], Type: Variable, Align: 8, Size: 336

which is good! If I flip on debug info and rebuild, this looks like:

drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3599:1: remark: 
Function: mlx5e_setup_tc
...
Offset: [SP-400], Type: Variable, Align: 8, Size: 352
    old_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2934
    old_chs @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2958
    new_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3539
Offset: [SP-752], Type: Variable, Align: 8, Size: 352
    new_chs @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3000
Offset: [SP-1088], Type: Variable, Align: 8, Size: 336
    new_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3424

Which is pretty awesome!
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlx5/core/en_main.c#n3424 for the last one, which shows we should probably be heap allocating instances of struct mlx5e_params rather than stack allocating them!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlx5/core/en_main.c#n3000 shows the same for struct mlx5e_channels. Cool stuff! Now we can finally debug -Wframe-larger-than=!!!

clang/test/Frontend/stack-layout-remark.c

9

Please update:

1. the patch description/commit message
2. clang/docs/ReleaseNotes.rst
   
   to mention this new flag. I kind of wish that -Wstack-frame-larger-than= alluded to this somehow.

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

66

@paulkirth make sure to mark these code review comments as done when implemented, please!

192

do we need EndIdx, or can we simply use Idx != ObjEnd as the loop terminating condition?

Doesn't look like we use ObjBeg afterwards either; is that necessary? Seems like the call to MFI.getObjectIndexBegin(); could happen in the initialization list of this for loop?

201–203

Consider implementing operator< on SlotData; then I think you can simply call std::sort on SlotInfo and drop this lamda.

207–209

remove braces
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

217

If you sink this def into the for loop, then you don't need to clear it.

221–223

remove braces
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

228–229

I guess this can be removed since the for loop below wont do anything if there's 0 memoperands?

llvm/test/CodeGen/AArch64/O0-pipeline.ll

76–77

Dang, this adds a bunch of passes to O0 pipelines...any creative ideas on how to not do that?

llvm/test/CodeGen/AArch64/arm64-opt-remarks-lazy-bfi.ll

43–46

what's going on in this test? Looks like the pass is being run twice or something?

[nickdesaulniers]

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

45

Consider replacing uses of PassName with DEBUG_TYPE since they have the same value.

99–100

consider sinking this closer to use. If you only call one method on it, and it could fit in one line, consider not even creating a variable. i.e.
getAnalysis<MachineOptimizationRemarkEmitterPass>().getORE().emit(ReM)

107

can you sink the call to genSlotDbgMapping() into this arg list? SlotMap seems unreferenced otherwise.

[nickdesaulniers]

clang/test/Frontend/stack-layout-remark.c

9

Perhaps in the documentation for -Wframe-larger-than=? i.e. adding a code Documentation = [{}] block to BackendFrameLargerThan record in clang/include/clang/Basic/DiagnosticGroups.td or something.

[paulkirth]

Address comments

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

45

ugh, I forgot to update that after adding DEBUG_TYPE. Thanks for pointing that out.

107

surprisingly this resulted in a compiler error:

StackFrameLayoutAnalysisPass.cpp:104:37: error: non-const lvalue reference to type 'SmallDenseMap<...>' cannot bind to a temporary of type 'SmallDenseMap<...>'
    emitStackFrameLayoutRemarks(MF, genSlotDbgMapping(MF), Rem);

So I've just moved it into emitStackFrameLayoutRemarks() and dropped the parameter, which avoids the issue entirely. Since SlotMap is only used there now, it makes more sense to structure the code like this anyway.

217

for some reason I was under the impression that our style guidelines prefered using clear in situations like this, but I can't find it so I think my brain tricked me. Thanks for pointing that out.

[paulkirth]

In D135488#4048380, @nickdesaulniers wrote:

It would be really nice if we could limit this to a specific function somehow.

I think you can do that, right ?
see:
https://llvm.org/docs/Remarks.html#cmdoption-pass-remarks-filter
https://llvm.org/docs/Remarks.html#cmdoption-pass-remarks-filter

Quick feedback from giving Diff 488727 a spin on the Linux kernel:

via ARCH=arm make LLVM=1 -j128 -s allyesconfig all I found:

  CC      drivers/net/ethernet/mellanox/mlx5/core/en_main.o
drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3597:12: error: stack frame size (1256) exceeds limit (1024) in 'mlx5e_setup_tc' [-Werror,-Wframe-larger-than]
static int mlx5e_setup_tc(struct net_device *dev, enum tc_setup_type type,
           ^

When I rebuild with:

ARCH=arm make LLVM=1 -j128 drivers/net/ethernet/mellanox/mlx5/core/en_main.o KCFLAGS=-Rpass-analysis=stack-frame-layout

I get a printout of the stack usage of every function in this TU. That's 1929 lines of text output...I only care about mlx5e_setup_tc. Is there a way to limit that?

see: https://llvm.org/docs/Remarks.html#cmdoption-pass-remarks-filter

If that doesn't sort you out, we can probably do something about this. In the worst case we'd need to make this a bigger pass, and also emit diagnostics for stack size, etc instead of in prologue/epilogue inserter. That was mentioned earlier, but I think that should be a separate change.

Filtering through the logs though, I do see:

drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3599:1: remark: 
Function: mlx5e_setup_tc
...
Offset: [SP-400], Type: Variable, Align: 8, Size: 352
Offset: [SP-752], Type: Variable, Align: 8, Size: 352
Offset: [SP-1088], Type: Variable, Align: 8, Size: 336

which is good! If I flip on debug info and rebuild, this looks like:

drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3599:1: remark: 
Function: mlx5e_setup_tc
...
Offset: [SP-400], Type: Variable, Align: 8, Size: 352
    old_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2934
    old_chs @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2958
    new_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3539
Offset: [SP-752], Type: Variable, Align: 8, Size: 352
    new_chs @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3000
Offset: [SP-1088], Type: Variable, Align: 8, Size: 336
    new_params @ drivers/net/ethernet/mellanox/mlx5/core/en_main.c:3424

Which is pretty awesome!
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlx5/core/en_main.c#n3424 for the last one, which shows we should probably be heap allocating instances of struct mlx5e_params rather than stack allocating them!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlx5/core/en_main.c#n3000 shows the same for struct mlx5e_channels. Cool stuff! Now we can finally debug -Wframe-larger-than=!!!

Glad this helps! If you think of more issues, let me know.

[paulkirth]

clang/test/Frontend/stack-layout-remark.c

9

Will do on the ReleaseNotes, but I'm a bit unsure what you want in the summary. It mentions the motivation and describe what this pass is for/does using remarks. Is there something else it should say?

9

Perhaps in the documentation for -Wframe-larger-than=? i.e. adding a code Documentation = [{}] block to BackendFrameLargerThan record in clang/include/clang/Basic/DiagnosticGroups.td or something.

Hmm, I'll take a look there, but I'm not 100% sure I follow what you mean.

are you after somethng like this when frame-larger-than diagnostics happen:

you can debug this by adding -Rpass-analysis=stack-frame-layout -mllvm -pass-remarks-filter=<functionname>

or something like that?

[thegameg]

In D135488#4048854, @paulkirth wrote:

In D135488#4048380, @nickdesaulniers wrote:

It would be really nice if we could limit this to a specific function somehow.

I think you can do that, right ?
see:
https://llvm.org/docs/Remarks.html#cmdoption-pass-remarks-filter

This filters on the Name of the remark, so here it would be stack-frame-layout.

I think a -Rpass-func-filter=<regex> would be a great addition.

[paulkirth]

llvm/test/CodeGen/AArch64/O0-pipeline.ll

76–77

This seems to be the norm w/ other Analysis passes, or anything that uses remarks, really.

I'm not really sure what we can do about that other than to move this into an existing pass that already uses remarks. I didn't see any good candidates at the point in the pipeline that we'd like to run this though.

llvm/test/CodeGen/AArch64/arm64-opt-remarks-lazy-bfi.ll

43–46

not sure I follow. The block here is executing the pass then freeing the pass. I tried to follow the pattern used around this, but we could change it to

HOTNESS:      Executing Pass 'Stack Frame Layout Analysis'
HOTNESS:      Freeing Pass 'Stack Frame Layout Analysis'

and skip the rest

[paulkirth]

In D135488#4048869, @thegameg wrote:

In D135488#4048854, @paulkirth wrote:

In D135488#4048380, @nickdesaulniers wrote:

It would be really nice if we could limit this to a specific function somehow.

I think you can do that, right ?
see:
https://llvm.org/docs/Remarks.html#cmdoption-pass-remarks-filter

This filters on the Name of the remark, so here it would be stack-frame-layout.

I think a -Rpass-func-filter=<regex> would be a great addition.

That's right. I misremembered. I think when this was a normal printing pass you could filter w/ -filter-print-funcs=foo but I don't think that works now

[paulkirth]

Actually if we add

if (!isFunctionInPrintList(MF.getName()))
     return false;

we can filter by name

[nickdesaulniers]

In D135488#4049035, @paulkirth wrote:

Actually if we add

if (!isFunctionInPrintList(MF.getName()))
     return false;

we can filter by name

Does name mangling complicate that? Perhaps a C++ user would give an unmangled name, but MF would be looking at mangled names?

Anyways, it's not a pressing issue. I won't block this patch on that. I just redirect all the output to a file then scan that.

Same thing about adding passes to -O0. Someone might care about that, but I don't.

Nice work @paulkirth . I'm excited to use this to help us better understand and reduce our stack usage in the Linux kernel!

llvm/test/CodeGen/AArch64/arm64-opt-remarks-lazy-bfi.ll

43–46

Oops, I missed the first instance is Executing then the second is Freeing. NVM!

[nickdesaulniers]

Sorry, mind adding the documentation, too?

clang/test/Frontend/stack-layout-remark.c

9

Hmm, I'll take a look there, but I'm not 100% sure I follow what you mean.

are you after somethng like this when frame-larger-than diagnostics happen:

you can debug this by adding -Rpass-analysis=stack-frame-layout -mllvm -pass-remarks-filter=<functionname>

or something like that?

Basically, my concern is "how will other developers not cc'ed on this phab review ever find this nifty new flag?" If -Wframe-larger-than= doesn't print info about it, then we should at least have it in our docs.

The last sentence you suggested is exactly what I had in mind.

[thegameg]

In D135488#4049050, @nickdesaulniers wrote:

In D135488#4049035, @paulkirth wrote:

Actually if we add

if (!isFunctionInPrintList(MF.getName()))
     return false;

we can filter by name

I would rather have a more generic mechanism for remarks or diagnostics in general. Even if it uses isFunctionInPrintList, I'd rather have a real flag that doesn't require -mllvm.

Does name mangling complicate that? Perhaps a C++ user would give an unmangled name, but MF would be looking at mangled names?

Agreed. A regex would help a little there.

Anyways, it's not a pressing issue. I won't block this patch on that. I just redirect all the output to a file then scan that.

You can easily process the yaml output from -fsave-optimization-record with the optrecord module:

import optrecord
import re

all_remarks, file_remarks, _ = optrecord.gather_results(optrecord.find_opt_files(<INPUT_FILE>), 1, False)
for r in optrecord.itervalues(all_remarks):
  if re.match(<REGEX>, r.Function):
    print(r)

[nickdesaulniers]

In D135488#4049075, @thegameg wrote:

You can easily...

I'll just note that v1 of this patch IIRC was a note on the single individual instance of the -Wframe-larger-than= diagnostic. No additional flags for optimization remarks, no (large) dump of stack frame info for non-interesting functions, no python module writing necessary.

I recognize that this approach is a compromise, and it's not worth going back and forth.

But the point of this is to simplify the developer experience when -Wframe-larger-than= is encountered. Let's not lose sight of that.

[nickdesaulniers]

@paulkirth please don't forget to update the commit description with that flag so that I don't have to read the contents of the commit to find this flag again. If you're using arc diff to upload the patch, the --verbatim flag will update the phab description, IIRC.

[paulkirth]

Address comments

• Take a stab a ReleaseNotes
• Update -Wframe-larger-than documentation to reference this pass
• Enable filtering output from this pass by function name

[paulkirth]

Fix documentation string, since it was invalid formatting for the rst file.

Also since code blocks don't render correctly in the html, write the documentation so that its usable without the code examples

[paulkirth]

Update summary

[paulkirth]

In D135488#4049075, @thegameg wrote:

I would rather have a more generic mechanism for remarks or diagnostics in general. Even if it uses isFunctionInPrintList, I'd rather have a real flag that doesn't require -mllvm.

Agreed. I'm going to opt into the isFunctionInPrintList for now. If you feel strongly, I can remove it, but it seems like a useful compromise.

In D135488#4049050, @nickdesaulniers wrote:

Does name mangling complicate that? Perhaps a C++ user would give an unmangled name, but MF would be looking at mangled names?

It will absolutely expect the mangled name. We may want to look at the other filtering facilities we have available too. Like we have those sanitizer files, and some other matching that can use regex. XRay had some logic for that stuff too, in addition to the things already in sanitizer common, IIRC.

clang/test/Frontend/stack-layout-remark.c

9

The last sentence you suggested is exactly what I had in mind.

Maybe we should follow this patch up w/ a change to the frame larger than diagnostic?

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

221–223

BTW, didn't clang format used to fix these? I definitely remember it doing that. I don't have any special config I use, so it's just picking up project defaults. AFAIK it's still an option, but doesn't seem to be set for the LLVM config anymore. Did we change the behavior here for a reason?

I get caught by these a lot when a loop gets simplified.

llvm/test/CodeGen/AArch64/arm64-opt-remarks-lazy-bfi.ll

43–46

It's 100% non-obvious. It took me a bit to figure out that was how these worked when I added these.

[paulkirth]

Fix test for Windows. I had missed one of the file paths in YAML.

[paulkirth]

@nickdesaulniers @thegameg Are we happy w/ the ReleaseNotes and the documentation changes? If so, I'll land this, but I wasn't sure either of you saw those changes ... or if using isFunctionInPrintList for now is a good choice until we can implement filtering for remarks.

[chapuni]

This failed on some environments. See https://lab.llvm.org/buildbot/#/builders/109/builds/55534

clang/test/Frontend/stack-layout-remark.c

25

Line: might be fed to the next line. I suggest;

// YAML: DebugLoc:        { File: '{{.*}}stack-layout-remark.c',{{[:space:]}}Line: [[# @LINE + 24]],

225

ditto.

[chapuni]

clang/test/Frontend/stack-layout-remark.c

25

typo. {{[:space:]}}*

[paulkirth]

Use more flexible whitespace matching

[paulkirth]

@chapuni Thanks for the suggestion. It didn't occur to me that it could break the lines like that.

[chapuni]

Thanks. I have noticed I suggested re-typo. (I didn't amend it since I thought it was obvious)

[paulkirth]

Rebase

[paulkirth]

This broke a reverse iteration bot: https://lab.llvm.org/buildbot#builders/54/builds/3337

Forward fix in: https://reviews.llvm.org/D142127

clang/docs/ReleaseNotes.rst

struct bar {
       int b[0]; // NOT a flexible array member.
     };
 
 - Added ``-fmodule-output`` to enable the one-phase compilation model for
   standard C++ modules. See
   `Standard C++ Modules <https://clang.llvm.org/docs/StandardCPlusPlusModules.html>`_
   for more information.
 
+- Added ``-Rpass-analysis=stack-frame-layout`` which will emit new diagnostic
+  information about the layout of stack frames through the remarks
+  infrastructure. Since it uses remarks the diagnostic information is available
+  both on the CLI, and in a machine readable format.
+
 Deprecated Compiler Flags
 -------------------------
 - ``-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang``
   has been deprecated. The flag will be removed in Clang 18.
   ``-ftrivial-auto-var-init=zero`` is now available unconditionally, to be
   compatible with GCC.
 - ``-fcoroutines-ts`` has been deprecated. The flag will be removed in Clang 17.
   Please use ``-std=c++20`` or higher to use standard C++ coroutines instead.

clang/include/clang/Basic/DiagnosticGroups.td

 def OpenMP : DiagGroup<"openmp", [
     SourceUsesOpenMP, OpenMPClauses, OpenMPLoopForm, OpenMPTarget,
     OpenMPMapping, OpenMP51Ext
   ]>;
 
 // Backend warnings.
 def BackendInlineAsm : DiagGroup<"inline-asm">;
 def BackendSourceMgr : DiagGroup<"source-mgr">;
-def BackendFrameLargerThan : DiagGroup<"frame-larger-than">;
+def BackendFrameLargerThan : DiagGroup<"frame-larger-than">{
+ code Documentation = [{
+More fine grained information about the stack layout is available by adding the
+`-Rpass-analysis=stack-frame-layout` command-line flag to the compiler
+invocation.
+
+The diagnostic information can be saved to a file in a machine readable format,
+like YAML by adding the `-foptimization-record-file=<file>` command-line flag.
+
+Results can be filtered by function name by passing 
+`-mllvm -filter-print-funcs=foo`, where `foo` is the target function's name.
+
+   .. code-block: console
+      clang -c a.cpp -Rpass-analysis=stack-frame-layout -mllvm -filter-print-funcs=foo
+
+   .. code-block: console
+      clang -c a.cpp -Rpass-analysis=stack-frame-layout -foptimization-record-file=<file>
+}];
+}
 // Compatibility flag name from old versions of Clang.
 def : DiagGroup<"frame-larger-than=", [BackendFrameLargerThan]>;
 def BackendPlugin : DiagGroup<"backend-plugin">;
 def RemarkBackendPlugin : DiagGroup<"remark-backend-plugin">;
 def BackendOptimizationRemark : DiagGroup<"pass">;
 def BackendOptimizationRemarkMissed : DiagGroup<"pass-missed">;
 def BackendOptimizationRemarkAnalysis : DiagGroup<"pass-analysis">;
 def BackendOptimizationFailure : DiagGroup<"pass-failed">;

clang/test/Frontend/stack-layout-remark.c

+// Check that backend stack layout diagnostics are working correctly with and
+// without debug information, and when optimizations are enabled
+//
+// REQUIRES: x86-registered-target
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: %clang_cc1 %s -emit-codegen-only -triple x86_64-unknown-linux-gnu -target-cpu corei7 -Rpass-analysis=stack-frame-layout -o /dev/null  -O0  2>&1 | FileCheck %s --check-prefix=O0-NODEBUG
+// RUN: %clang_cc1 %s -emit-codegen-only -triple x86_64-unknown-linux-gnu -target-cpu corei7 -Rpass-analysis=stack-frame-layout -o /dev/null  -O0  -debug-info-kind=constructor  -dwarf-version=5 -debugger-tuning=gdb 2>&1 | FileCheck %s --check-prefix=O0-DEBUG
+// RUN: %clang_cc1 %s -emit-codegen-only -triple x86_64-unknown-linux-gnu -target-cpu corei7 -funwind-tables=2 -O3 -Rpass-analysis=stack-frame-layout   -debug-info-kind=constructor  -dwarf-version=5 -debugger-tuning=gdb -opt-record-file %t/stack-layout-remark.c.yml -opt-record-passes stack-frame-layout 2>&1 | FileCheck %s --check-prefix=O3-DEBUG
+// RUN: cat %t/stack-layout-remark.c.yml | FileCheck %s --check-prefix=YAML
+
+#define NULL (void*)0
+
+extern void* allocate(unsigned size);
+extern void deallocate(void* ptr);
+extern int work(char *ary, int size);
+extern int rand(void);
+
+// Test YAML Ouput
+// YAML: --- !Analysis
+// YAML: Pass:            stack-frame-layout
+// YAML: Name:            StackLayout
+// YAML: DebugLoc:        { File: '{{.*}}stack-layout-remark.c',{{[[:space:]]*}}Line: [[# @LINE + 24]],
+// YAML: Function:        foo
+// YAML: Args:
+// YAML:   - Offset:          '-40'
+// YAML:   - Type:            Variable
+// YAML:   - Align:           '16'
+// YAML:   - Size:            '32'
+// YAML:   - DataLoc:         'a @ {{.*}}stack-layout-remark.c:[[# @LINE + 19]]'
+// YAML:   - DataLoc:         'f @ {{.*}}stack-layout-remark.c:[[# @LINE + 21]]'
+
+//      O0-NODEBUG: Function: foo
+// O0-NODEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O0-NODEBUG-NEXT: Offset: [SP-72], Type: Variable, Align: 16, Size: 32
+//
+//      O0-DEBUG: Function: foo
+// O0-DEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O0-DEBUG-NEXT:     a @ {{.*}}stack-layout-remark.c:[[# @LINE + 10]]
+// O0-DEBUG-NEXT: Offset: [SP-72], Type: Variable, Align: 16, Size: 32
+// O0-DEBUG-NEXT:     f @ {{.*}}stack-layout-remark.c:[[# @LINE + 11]]
+
+//      O3-DEBUG: Function: foo
+// O3-DEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O3-DEBUG-NEXT:     a @ {{.*}}stack-layout-remark.c:[[# @LINE + 4]]
+// O3-DEBUG-NEXT:     f @ {{.*}}stack-layout-remark.c:[[# @LINE + 6]]
+void foo() {
+  {
+    char a[32] = {0};
+    work(a, sizeof(a));
+  }
+  char f[32] = {0};
+  work(f, sizeof(f));
+}
+//      O0-NODEBUG: Function: bar
+// O0-NODEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O0-NODEBUG-NEXT: Offset: [SP-72], Type: Variable, Align: 16, Size: 32
+
+//      O0-DEBUG: Function: bar
+// O0-DEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O0-DEBUG-NEXT:     f @ {{.*}}stack-layout-remark.c:[[# @LINE + 10]]
+// O0-DEBUG-NEXT: Offset: [SP-72], Type: Variable, Align: 16, Size: 32
+// O0-DEBUG-NEXT:     a @ {{.*}}stack-layout-remark.c:[[# @LINE + 10]]
+
+//      O3-DEBUG: Function: bar
+// O3-DEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 16, Size: 32
+// O3-DEBUG-NEXT:     f @ {{.*}}stack-layout-remark.c:[[# @LINE + 4]]
+// O3-DEBUG-NEXT: Offset: [SP-72], Type: Variable, Align: 16, Size: 32
+// O3-DEBUG-NEXT:     a @ {{.*}}stack-layout-remark.c:[[# @LINE + 4]]
+void bar() {
+  char f[32] = {0};
+  {
+    char a[32] = {0};
+    work(a, sizeof(a));
+  }
+  work(f, sizeof(f));
+}
+
+struct Array {
+  int *data;
+  int size;
+};
+
+struct Result {
+  struct Array *data;
+  int sum;
+};
+
+//      O0-NODEBUG: Function: cleanup_array
+// O0-NODEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+
+//      O0-DEBUG: Function: cleanup_array
+// O0-DEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     a @ {{.*}}stack-layout-remark.c:[[# @LINE + 5]]
+
+//      O3-DEBUG: Function: cleanup_array
+//      O3-DEBUG: Function: cleanup_result
+// O3-DEBUG-NEXT: Offset: [SP-8], Type: Spill, Align: 16, Size: 8
+void cleanup_array(struct Array *a) {
+  if (!a)
+    return;
+  if (!a->data)
+    return;
+  deallocate(a->data);
+}
+
+//      O0-NODEBUG: Function: cleanup_result
+// O0-NODEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+
+//      O0-DEBUG: Function: cleanup_result
+// O0-DEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     res @ {{.*}}stack-layout-remark.c:[[# @LINE + 1]]
+void cleanup_result(struct Result *res) {
+  if (!res)
+    return;
+  if (!res->data)
+    return;
+  cleanup_array(res->data);
+  deallocate(res->data);
+}
+
+extern void use_dot_vector(struct Array *data);
+
+//      O0-NODEBUG: Function: do_work
+// O0-NODEBUG-NEXT: Offset: [SP-4], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-16], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-32], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-36], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-48], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-52], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-56], Type: Variable, Align: 4, Size: 4
+
+//      O0-DEBUG: Function: do_work
+// O0-DEBUG-NEXT: Offset: [SP-4], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT: Offset: [SP-16], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     A @ {{.*}}stack-layout-remark.c:[[# @LINE + 20]]
+// O0-DEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     B @ {{.*}}stack-layout-remark.c:[[# @LINE + 18]]
+// O0-DEBUG-NEXT: Offset: [SP-32], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     out @ {{.*}}stack-layout-remark.c:[[# @LINE + 16]]
+// O0-DEBUG-NEXT: Offset: [SP-36], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     len @ {{.*}}stack-layout-remark.c:[[# @LINE + 19]]
+// O0-DEBUG-NEXT: Offset: [SP-48], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     AB @ {{.*}}stack-layout-remark.c:[[# @LINE + 18]]
+// O0-DEBUG-NEXT: Offset: [SP-52], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     sum @ {{.*}}stack-layout-remark.c:[[# @LINE + 32]]
+// O0-DEBUG-NEXT: Offset: [SP-56], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     i @ {{.*}}stack-layout-remark.c:[[# @LINE + 31]]
+
+//      O3-DEBUG: Function: do_work
+// O3-DEBUG-NEXT: Offset: [SP-8], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-16], Type: Spill, Align: 8, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-24], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-32], Type: Spill, Align: 8, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-40], Type: Spill, Align: 16, Size: 8
+int do_work(struct Array *A, struct Array *B, struct Result *out) {
+  if (!A || !B)
+    return -1;
+  if (A->size != B->size)
+    return -1;
+  const int len = A->size;
+  struct Array *AB;
+  if (out->data == NULL) {
+    AB = (struct Array *)allocate(sizeof(struct Array));
+    AB->data = NULL;
+    AB->size = 0;
+    out->data = AB;
+  } else {
+    AB = out->data;
+  }
+
+  if (AB->data)
+    deallocate(AB->data);
+
+  AB->data = (int *)allocate(len * sizeof(int));
+  AB->size = len;
+
+  int sum = 0;
+  for (int i = 0; i < len; ++i) {
+    AB->data[i] = A->data[i] * B->data[i];
+    sum += AB->data[i];
+  }
+  return sum;
+}
+
+//      O0-NODEBUG: Function: gen_array
+// O0-NODEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-12], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-28], Type: Variable, Align: 4, Size: 4
+
+//      O0-DEBUG: Function: gen_array
+// O0-DEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT: Offset: [SP-12], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     size @ {{.*}}stack-layout-remark.c:[[# @LINE + 10]]
+// O0-DEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     res @ {{.*}}stack-layout-remark.c:[[# @LINE + 11]]
+// O0-DEBUG-NEXT: Offset: [SP-28], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     i @ {{.*}}stack-layout-remark.c:[[# @LINE + 13]]
+
+//      O3-DEBUG: Function: gen_array
+// O3-DEBUG-NEXT: Offset: [SP-8], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-16], Type: Spill, Align: 8, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-24], Type: Spill, Align: 16, Size: 8
+struct Array *gen_array(int size) {
+  if (size < 0)
+    return NULL;
+  struct Array *res = (struct Array *)allocate(sizeof(struct Array));
+  res->size = size;
+  res->data = (int *)allocate(size * sizeof(int));
+
+  for (int i = 0; i < size; ++i) {
+    res->data[i] = rand();
+  }
+
+  return res;
+}
+
+// YAML: --- !Analysis
+// YAML: Pass:            stack-frame-layout
+// YAML: Name:            StackLayout
+// YAML: DebugLoc:        { File: '{{.*}}stack-layout-remark.c',{{[[:space:]]*}}Line: [[# @LINE + 59]],
+// YAML: Function:        caller
+// YAML: Args:
+// YAML:   - Offset:          '-8'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '16'
+// YAML:   - Size:            '8'
+// YAML:   - Offset:          '-16'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '8'
+// YAML:   - Size:            '8'
+// YAML:   - Offset:          '-24'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '16'
+// YAML:   - Size:            '8'
+// YAML:   - Offset:          '-32'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '8'
+// YAML:   - Size:            '8'
+// YAML:   - Offset:          '-40'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '16'
+// YAML:   - Size:            '8'
+// YAML:   - Offset:          '-48'
+// YAML:   - Type:            Spill
+// YAML:   - Align:           '8'
+// YAML:   - Size:            '8'
+
+//      O0-NODEBUG: Function: caller
+// O0-NODEBUG-NEXT: Offset: [SP-4], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-16], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-32], Type: Variable, Align: 8, Size: 8
+// O0-NODEBUG-NEXT: Offset: [SP-36], Type: Variable, Align: 4, Size: 4
+// O0-NODEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 4, Size: 4
+
+//      O0-DEBUG: Function: caller
+// O0-DEBUG-NEXT: Offset: [SP-4], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT: Offset: [SP-8], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     size @ {{.*}}stack-layout-remark.c:[[# @LINE + 20]]
+// O0-DEBUG-NEXT: Offset: [SP-16], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     A @ {{.*}}stack-layout-remark.c:[[# @LINE + 19]]
+// O0-DEBUG-NEXT: Offset: [SP-24], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     B @ {{.*}}stack-layout-remark.c:[[# @LINE + 18]]
+// O0-DEBUG-NEXT: Offset: [SP-32], Type: Variable, Align: 8, Size: 8
+// O0-DEBUG-NEXT:     res @ {{.*}}stack-layout-remark.c:[[# @LINE + 17]]
+// O0-DEBUG-NEXT: Offset: [SP-36], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     ret @ {{.*}}stack-layout-remark.c:[[# @LINE + 16]]
+// O0-DEBUG-NEXT: Offset: [SP-40], Type: Variable, Align: 4, Size: 4
+// O0-DEBUG-NEXT:     err @ {{.*}}stack-layout-remark.c:[[# @LINE + 16]]
+
+//      O3-DEBUG: Function: caller
+// O3-DEBUG-NEXT: Offset: [SP-8], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-16], Type: Spill, Align: 8, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-24], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-32], Type: Spill, Align: 8, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-40], Type: Spill, Align: 16, Size: 8
+// O3-DEBUG-NEXT: Offset: [SP-48], Type: Spill, Align: 8, Size: 8
+int caller() {
+  const int size = 100;
+  struct Array *A = gen_array(size);
+  struct Array *B = gen_array(size);
+  struct Result *res = (struct Result *)allocate(sizeof(struct Result));
+  int ret = -1;
+
+  int err = do_work(A, B, res);
+  if (err == -1) {
+    goto cleanup;
+  }
+
+  ret = res->sum;
+  if (ret == -1)
+    return caller();
+
+  use_dot_vector(res->data);
+
+cleanup:
+  cleanup_array(A);
+  cleanup_array(B);
+  cleanup_result(res);
+
+  return ret;
+}
+

llvm/include/llvm/CodeGen/Passes.h

namespace llvm {
   MachineFunctionPass *createMachineFunctionSplitterPass();
 
   /// MachineFunctionPrinter pass - This pass prints out the machine function to
   /// the given stream as a debugging tool.
   MachineFunctionPass *
   createMachineFunctionPrinterPass(raw_ostream &OS,
                                    const std::string &Banner ="");
 
+  /// StackFramePrinter pass - This pass prints out the machine function's
+  /// stack frame to the given stream as a debugging tool.
+  MachineFunctionPass *createStackFrameLayoutAnalysisPass();
+
   /// MIRPrinting pass - this pass prints out the LLVM IR into the given stream
   /// using the MIR serialization format.
   MachineFunctionPass *createPrintMIRPass(raw_ostream &OS);
 
   /// This pass resets a MachineFunction when it has the FailedISel property
   /// as if it was just created.
   /// If EmitFallbackDiag is true, the pass will emit a
   /// DiagnosticInfoISelFallback for every MachineFunction it resets.
namespace llvm {
   /// This pass performs instruction combining using trace metrics to estimate
   /// critical-path and resource depth.
   extern char &MachineCombinerID;
 
   /// StackSlotColoring - This pass performs stack coloring and merging.
   /// It merges disjoint allocas to reduce the stack size.
   extern char &StackColoringID;
 
+  /// StackFramePrinter - This pass prints the stack frame layout and variable
+  /// mappings.
+  extern char &StackFrameLayoutAnalysisPassID;
+
   /// IfConverter - This pass performs machine code if conversion.
   extern char &IfConverterID;
 
   FunctionPass *createIfConverter(
       std::function<bool(const MachineFunction &)> Ftor);
 
   /// MachineBlockPlacement - This pass places basic blocks based on branch
   /// probabilities.

llvm/include/llvm/InitializePasses.h

 void initializeSimpleLoopUnswitchLegacyPassPass(PassRegistry&);
 void initializeSingleLoopExtractorPass(PassRegistry&);
 void initializeSinkingLegacyPassPass(PassRegistry&);
 void initializeSjLjEHPreparePass(PassRegistry&);
 void initializeSlotIndexesPass(PassRegistry&);
 void initializeSpeculativeExecutionLegacyPassPass(PassRegistry&);
 void initializeSpillPlacementPass(PassRegistry&);
 void initializeStackColoringPass(PassRegistry&);
+void initializeStackFrameLayoutAnalysisPassPass(PassRegistry &);
 void initializeStackMapLivenessPass(PassRegistry&);
 void initializeStackProtectorPass(PassRegistry&);
 void initializeStackSafetyGlobalInfoWrapperPassPass(PassRegistry &);
 void initializeStackSafetyInfoWrapperPassPass(PassRegistry &);
 void initializeStackSlotColoringPass(PassRegistry&);
 void initializeStraightLineStrengthReduceLegacyPassPass(PassRegistry &);
 void initializeStripDeadDebugInfoPass(PassRegistry&);
 void initializeStripDeadPrototypesLegacyPassPass(PassRegistry&);

llvm/lib/CodeGen/CMakeLists.txt

add_llvm_component_library(LLVMCodeGen
   SelectOptimize.cpp
   ShadowStackGCLowering.cpp
   ShrinkWrap.cpp
   SjLjEHPrepare.cpp
   SlotIndexes.cpp
   SpillPlacement.cpp
   SplitKit.cpp
   StackColoring.cpp
+  StackFrameLayoutAnalysisPass.cpp
   StackMapLivenessAnalysis.cpp
   StackMaps.cpp
   StackProtector.cpp
   StackSlotColoring.cpp
   SwiftErrorValueTracking.cpp
   SwitchLoweringUtils.cpp
   TailDuplication.cpp
   TailDuplicator.cpp

llvm/lib/CodeGen/CodeGen.cpp

void llvm::initializeCodeGen(PassRegistry &Registry) {
   initializeRenameIndependentSubregsPass(Registry);
   initializeSafeStackLegacyPassPass(Registry);
   initializeSelectOptimizePass(Registry);
   initializeShadowStackGCLoweringPass(Registry);
   initializeShrinkWrapPass(Registry);
   initializeSjLjEHPreparePass(Registry);
   initializeSlotIndexesPass(Registry);
   initializeStackColoringPass(Registry);
+  initializeStackFrameLayoutAnalysisPassPass(Registry);
   initializeStackMapLivenessPass(Registry);
   initializeStackProtectorPass(Registry);
   initializeStackSlotColoringPass(Registry);
   initializeStripDebugMachineModulePass(Registry);
   initializeTailDuplicatePass(Registry);
   initializeTargetPassConfigPass(Registry);
   initializeTwoAddressInstructionPassPass(Registry);
   initializeTypePromotionLegacyPass(Registry);

llvm/lib/CodeGen/StackFrameLayoutAnalysisPass.cpp

+//===-- StackFrameLayoutAnalysisPass.cpp
+//------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// StackFrameLayoutAnalysisPass implementation. Outputs information about the
+// layout of the stack frame, using the remarks interface. On the CLI it prints
+// a textual representation of the stack frame. When possible it prints the
+// values that occupy a stack slot using any available debug information. Since
+// output is remarks based, it is also available in a machine readable file
+// format, such as YAML.
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm/Analysis/OptimizationRemarkEmitter.h"
+#include "llvm/CodeGen/MachineFrameInfo.h"
+#include "llvm/CodeGen/MachineFunction.h"
+#include "llvm/CodeGen/MachineFunctionPass.h"
+#include "llvm/CodeGen/MachineOptimizationRemarkEmitter.h"
+#include "llvm/CodeGen/Passes.h"
+#include "llvm/CodeGen/SlotIndexes.h"
+#include "llvm/CodeGen/StackProtector.h"
+#include "llvm/CodeGen/TargetFrameLowering.h"
+#include "llvm/CodeGen/TargetSubtargetInfo.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/PrintPasses.h"
+#include "llvm/InitializePasses.h"
+#include "llvm/Support/Debug.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include <sstream>
+
+using namespace llvm;
+
+#define DEBUG_TYPE "stack-frame-layout"
+
+namespace {
+
+/// StackFrameLayoutAnalysisPass - This is a pass to dump the stack frame of a
+/// MachineFunction.
+///
+struct StackFrameLayoutAnalysisPass : public MachineFunctionPass {
+  using SlotDbgMap =
+      SmallDenseMap<int, SmallPtrSet<const DILocalVariable *, 4>>;
+  static char ID;
+
+  enum SlotType {
+    Spill,          // a Spill slot
+    StackProtector, // Stack Protector slot
+    Variable,       // a slot used to store a local data (could be a tmp)
+    Invalid         // It's an error for a slot to have this type
+  };
+
+  struct SlotData {
+    int Slot;
+    int Size;
+    int Align;
+    int Offset;
+    SlotType SlotTy;
+
+    SlotData(const MachineFrameInfo &MFI, const int ValOffset, const int Idx)
+        : Slot(Idx), Size(MFI.getObjectSize(Idx)),
+          Align(MFI.getObjectAlign(Idx).value()),
+          Offset(MFI.getObjectOffset(Idx) - ValOffset), SlotTy(Invalid) {
+      if (MFI.isSpillSlotObjectIndex(Idx))
+        SlotTy = SlotType::Spill;
+      else if (Idx == MFI.getStackProtectorIndex())
+        SlotTy = SlotType::StackProtector;
+      else
+        SlotTy = SlotType::Variable;
+    }
+
+    // we use this to sort in reverse order, so that the layout is displayed
+    // correctly
+    bool operator<(const SlotData &Rhs) const { return Offset > Rhs.Offset; }
+  };
+
+  StackFrameLayoutAnalysisPass() : MachineFunctionPass(ID) {}
+
+  StringRef getPassName() const override {
+    return "Stack Frame Layout Analysis";
+  }
+
+  void getAnalysisUsage(AnalysisUsage &AU) const override {
+    AU.setPreservesAll();
+    MachineFunctionPass::getAnalysisUsage(AU);
+    AU.addRequired<MachineOptimizationRemarkEmitterPass>();
+  }
+
+  bool runOnMachineFunction(MachineFunction &MF) override {
+    // TODO: We should implement a similar filter for remarks:
+    //   -Rpass-func-filter=<regex>
+    if (!isFunctionInPrintList(MF.getName()))
+      return false;
+
+    LLVMContext &Ctx = MF.getFunction().getContext();
+    if (!Ctx.getDiagHandlerPtr()->isAnalysisRemarkEnabled(DEBUG_TYPE))
+      return false;
+
+    MachineOptimizationRemarkAnalysis Rem(DEBUG_TYPE, "StackLayout",
+                                          MF.getFunction().getSubprogram(),
+                                          &MF.front());
+    Rem << ("\nFunction: " + MF.getName()).str();
+    emitStackFrameLayoutRemarks(MF, Rem);
+    getAnalysis<MachineOptimizationRemarkEmitterPass>().getORE().emit(Rem);
+    return false;
+  }
+
+  std::string getTypeString(SlotType Ty) {
+    switch (Ty) {
+    case SlotType::Spill:
+      return "Spill";
+    case SlotType::StackProtector:
+      return "Protector";
+    case SlotType::Variable:
+      return "Variable";
+    default:
+      llvm_unreachable("bad slot type for stack layout");
+    }
+  }
+
+  void emitStackSlotRemark(const MachineFunction &MF, const SlotData &D,
+                           MachineOptimizationRemarkAnalysis &Rem) {
+    // To make it easy to understand the stack layout from the CLI, we want to
+    // print each slot like the following:
+    //
+    //   Offset: [SP+8], Type: Spill, Align: 8, Size: 16
+    //       foo @ /path/to/file.c:25
+    //       bar @ /path/to/file.c:35
+    //
+    // Which prints the size, alignment, and offset from the SP at function
+    // entry.
+    //
+    // But we also want the machine readable remarks data to be nicely
+    // organized. So we print some additional data as strings for the CLI
+    // output, but maintain more structured data for the YAML.
+    //
+    // For example we store the Offset in YAML as:
+    //    ...
+    //    - Offset: -8
+    //
+    // But we print it to the CLI as
+    //   Offset: [SP-8]
+
+    // Negative offsets will print a leading `-`, so only add `+`
+    std::string Prefix =
+        formatv("\nOffset: [SP{0}", (D.Offset < 0) ? "" : "+").str();
+    Rem << Prefix << ore::NV("Offset", D.Offset)
+        << "], Type: " << ore::NV("Type", getTypeString(D.SlotTy))
+        << ", Align: " << ore::NV("Align", D.Align)
+        << ", Size: " << ore::NV("Size", D.Size);
+  }
+
+  void emitSourceLocRemark(const MachineFunction &MF, const DILocalVariable *N,
+                           MachineOptimizationRemarkAnalysis &Rem) {
+    std::string Loc =
+        formatv("{0} @ {1}:{2}", N->getName(), N->getFilename(), N->getLine())
+            .str();
+    Rem << "\n    " << ore::NV("DataLoc", Loc);
+  }
+
+  void emitStackFrameLayoutRemarks(MachineFunction &MF,
+                                   MachineOptimizationRemarkAnalysis &Rem) {
+    const MachineFrameInfo &MFI = MF.getFrameInfo();
+    if (!MFI.hasStackObjects())
+      return;
+
+    // ValOffset is the offset to the local area from the SP at function entry.
+    // To display the true offset from SP, we need to subtract ValOffset from
+    // MFI's ObjectOffset.
+    const TargetFrameLowering *FI = MF.getSubtarget().getFrameLowering();
+    const int ValOffset = (FI ? FI->getOffsetOfLocalArea() : 0);
+
+    LLVM_DEBUG(dbgs() << "getStackProtectorIndex =="
+                      << MFI.getStackProtectorIndex() << "\n");
+
+    std::vector<SlotData> SlotInfo;
+    SmallDenseMap<int, int> SlotOffsetMap;
+
+    const unsigned int NumObj = MFI.getNumObjects();
+    SlotInfo.reserve(NumObj);
+    SlotOffsetMap.reserve(NumObj);
+    // initialize slot info
+    for (int Idx = MFI.getObjectIndexBegin(), EndIdx = MFI.getObjectIndexEnd();
+         Idx != EndIdx; ++Idx) {
+      if (MFI.isDeadObjectIndex(Idx))
+        continue;
+      auto &Inserted = SlotInfo.emplace_back(MFI, ValOffset, Idx);
+      SlotOffsetMap[Inserted.Slot] = Inserted.Offset;
+    }
+
+    // sort the ordering, to match the actual layout in memory
+    llvm::sort(SlotInfo);
+
+    SlotDbgMap SlotMap = genSlotDbgMapping(MF);
+
+    for (const SlotData &Info : SlotInfo) {
+      emitStackSlotRemark(MF, Info, Rem);
+      for (const DILocalVariable *N : SlotMap[Info.Slot])
+        emitSourceLocRemark(MF, N, Rem);
+    }
+  }
+
+  // We need to generate a mapping of slots to the values that are stored to
+  // them. This information is lost by the time we need to print out the frame,
+  // so we reconstruct it here by walking the CFG, and generating the mapping.
+  SlotDbgMap genSlotDbgMapping(MachineFunction &MF) {
+    SlotDbgMap SlotDebugMap;
+
+    // add variables to the map
+    for (MachineFunction::VariableDbgInfo &DI : MF.getVariableDbgInfo())
+      SlotDebugMap[DI.Slot].insert(DI.Var);
+
+    // Then add all the spills that have debug data
+    for (MachineBasicBlock &MBB : MF) {
+      for (MachineInstr &MI : MBB) {
+        for (MachineMemOperand *MO : MI.memoperands()) {
+          if (!MO->isStore())
+            continue;
+          auto *FI = dyn_cast_or_null<FixedStackPseudoSourceValue>(
+              MO->getPseudoValue());
+          if (!FI)
+            continue;
+          int FrameIdx = FI->getFrameIndex();
+          SmallVector<MachineInstr *> Dbg;
+          MI.collectDebugValues(Dbg);
+
+          for (MachineInstr *MI : Dbg)
+            SlotDebugMap[FrameIdx].insert(MI->getDebugVariable());
+        }
+      }
+    }
+
+    return SlotDebugMap;
+  }
+};
+
+char StackFrameLayoutAnalysisPass::ID = 0;
+} // namespace
+
+char &llvm::StackFrameLayoutAnalysisPassID = StackFrameLayoutAnalysisPass::ID;
+INITIALIZE_PASS(StackFrameLayoutAnalysisPass, "stack-frame-layout",
+                "Stack Frame Layout", false, false)
+
+namespace llvm {
+/// Returns a newly-created StackFrameLayout pass.
+MachineFunctionPass *createStackFrameLayoutAnalysisPass() {
+  return new StackFrameLayoutAnalysisPass();
+}
+
+} // namespace llvm

llvm/lib/CodeGen/TargetPassConfig.cpp

void TargetPassConfig::addMachinePasses() {
   } else if (TM->Options.EnableMachineFunctionSplitter ||
              EnableMachineFunctionSplitter) {
     addPass(createMachineFunctionSplitterPass());
   }
 
   if (!DisableCFIFixup && TM->Options.EnableCFIFixup)
     addPass(createCFIFixup());
 
+  PM->add(createStackFrameLayoutAnalysisPass());
+
   // Add passes that directly emit MI after all other MI passes.
   addPreEmitPass2();
 
   AddingMachinePasses = false;
 }
 
 /// Add passes that optimize machine instructions in SSA form.
 void TargetPassConfig::addMachineSSAOptimization() {

llvm/test/CodeGen/AArch64/O0-pipeline.ll

 ; CHECK-NEXT:       Workaround A53 erratum 835769 pass
 ; CHECK-NEXT:       AArch64 Branch Targets
 ; CHECK-NEXT:       Branch relaxation pass
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
 ; CHECK-NEXT:       Insert CFI remember/restore state instructions
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       Unpack machine instruction bundles
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       AArch64 Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction
 
 define void @f() {
   ret void
 }

llvm/test/CodeGen/AArch64/O3-pipeline.ll

 ; CHECK-NEXT:       AArch64 Compress Jump Tables
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
 ; CHECK-NEXT:     Machine Outliner
 ; CHECK-NEXT:     FunctionPass Manager
 ; CHECK-NEXT:       Insert CFI remember/restore state instructions
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       Unpack machine instruction bundles
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       AArch64 Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction
 ; CHECK-NEXT: Pass Arguments:  -domtree
 ; CHECK-NEXT:   FunctionPass Manager
 ; CHECK-NEXT:     Dominator Tree Construction

llvm/test/CodeGen/AArch64/arm64-opt-remarks-lazy-bfi.ll

 ; HOTNESS:      Freeing Pass 'Machine Outliner'
 ; HOTNESS-NEXT:  Executing Pass 'Function Pass Manager'
 ; HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
 ; HOTNESS-NEXT: Executing Pass 'Insert CFI remember/restore state instructions' on Function 'empty_func'
 ; HOTNESS-NEXT: Freeing Pass 'Insert CFI remember/restore state instructions' on Function 'empty_func'
 ; HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
+; HOTNESS-NEXT: Executing Pass 'Lazy Machine Block Frequency Analysis'
+; HOTNESS-NEXT: Executing Pass 'Machine Optimization Remark Emitter'
+; HOTNESS:      Executing Pass 'Stack Frame Layout Analysis'
+; HOTNESS-NEXT: Freeing Pass 'Machine Optimization Remark Emitter'
+; HOTNESS-NEXT: Freeing Pass 'Lazy Machine Block Frequency Analysis'
+; HOTNESS-NEXT: Freeing Pass 'Stack Frame Layout Analysis'
 ; HOTNESS-NEXT: Executing Pass 'Unpack machine instruction bundles'
 ; HOTNESS-NEXT: Freeing Pass 'Unpack machine instruction bundles'
 ; HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
 ; HOTNESS-NEXT: Executing Pass 'Lazy Machine Block Frequency Analysis'
 ; HOTNESS-NEXT: Executing Pass 'Machine Optimization Remark Emitter'
 ; HOTNESS-NEXT: Building MachineBlockFrequencyInfo on the fly
 ; HOTNESS-NEXT: Building LoopInfo on the fly

 ; NO_HOTNESS:      Freeing Pass 'Machine Outliner'
 ; NO_HOTNESS-NEXT:  Executing Pass 'Function Pass Manager'
 ; NO_HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; NO_HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
 ; NO_HOTNESS-NEXT: Executing Pass 'Insert CFI remember/restore state instructions' on Function 'empty_func'
 ; NO_HOTNESS-NEXT: Freeing Pass 'Insert CFI remember/restore state instructions' on Function 'empty_func'
 ; NO_HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; NO_HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
+; NO_HOTNESS-NEXT: Executing Pass 'Lazy Machine Block Frequency Analysis'
+; NO_HOTNESS-NEXT: Executing Pass 'Machine Optimization Remark Emitter'
+; NO_HOTNESS:      Executing Pass 'Stack Frame Layout Analysis'
+; NO_HOTNESS-NEXT: Freeing Pass 'Machine Optimization Remark Emitter'
+; NO_HOTNESS-NEXT: Freeing Pass 'Lazy Machine Block Frequency Analysis'
+; NO_HOTNESS-NEXT: Freeing Pass 'Stack Frame Layout Analysis'
 ; NO_HOTNESS-NEXT: Executing Pass 'Unpack machine instruction bundles'
 ; NO_HOTNESS-NEXT: Freeing Pass 'Unpack machine instruction bundles'
 ; NO_HOTNESS-NEXT: Executing Pass 'Verify generated machine code'
 ; NO_HOTNESS-NEXT: Freeing Pass 'Verify generated machine code'
 ; NO_HOTNESS-NEXT: Executing Pass 'Lazy Machine Block Frequency Analysis'
 ; NO_HOTNESS-NEXT: Executing Pass 'Machine Optimization Remark Emitter'
 ; NO_HOTNESS-NEXT: Executing Pass 'AArch64 Assembly Printer'
 

llvm/test/CodeGen/AMDGPU/llc-pipeline.ll

 ; GCN-O0-NEXT:        SI insert wait instructions
 ; GCN-O0-NEXT:        Insert required mode register values
 ; GCN-O0-NEXT:        SI Final Branch Preparation
 ; GCN-O0-NEXT:        Post RA hazard recognizer
 ; GCN-O0-NEXT:        Branch relaxation pass
 ; GCN-O0-NEXT:        Register Usage Information Collector Pass
 ; GCN-O0-NEXT:        Live DEBUG_VALUE analysis
 ; GCN-O0-NEXT:        Machine Sanitizer Binary Metadata
+; GCN-O0-NEXT:        Lazy Machine Block Frequency Analysis
+; GCN-O0-NEXT:        Machine Optimization Remark Emitter
+; GCN-O0-NEXT:        Stack Frame Layout Analysis
 ; GCN-O0-NEXT:    Function register usage analysis
 ; GCN-O0-NEXT:    FunctionPass Manager
 ; GCN-O0-NEXT:      Lazy Machine Block Frequency Analysis
 ; GCN-O0-NEXT:      Machine Optimization Remark Emitter
 ; GCN-O0-NEXT:      AMDGPU Assembly Printer
 ; GCN-O0-NEXT:      Free MachineFunction
 ; GCN-O0-NEXT:Pass Arguments:  -domtree
 ; GCN-O0-NEXT:  FunctionPass Manager

 ; GCN-O1-NEXT:        SI Final Branch Preparation
 ; GCN-O1-NEXT:        SI peephole optimizations
 ; GCN-O1-NEXT:        Post RA hazard recognizer
 ; GCN-O1-NEXT:        AMDGPU Insert Delay ALU
 ; GCN-O1-NEXT:        Branch relaxation pass
 ; GCN-O1-NEXT:        Register Usage Information Collector Pass
 ; GCN-O1-NEXT:        Live DEBUG_VALUE analysis
 ; GCN-O1-NEXT:        Machine Sanitizer Binary Metadata
+; GCN-O1-NEXT:        Lazy Machine Block Frequency Analysis
+; GCN-O1-NEXT:        Machine Optimization Remark Emitter
+; GCN-O1-NEXT:        Stack Frame Layout Analysis
 ; GCN-O1-NEXT:    Function register usage analysis
 ; GCN-O1-NEXT:    FunctionPass Manager
 ; GCN-O1-NEXT:      Lazy Machine Block Frequency Analysis
 ; GCN-O1-NEXT:      Machine Optimization Remark Emitter
 ; GCN-O1-NEXT:      AMDGPU Assembly Printer
 ; GCN-O1-NEXT:      Free MachineFunction
 ; GCN-O1-NEXT:Pass Arguments:  -domtree
 ; GCN-O1-NEXT:  FunctionPass Manager

 ; GCN-O1-OPTS-NEXT:        SI Final Branch Preparation
 ; GCN-O1-OPTS-NEXT:        SI peephole optimizations
 ; GCN-O1-OPTS-NEXT:        Post RA hazard recognizer
 ; GCN-O1-OPTS-NEXT:        AMDGPU Insert Delay ALU
 ; GCN-O1-OPTS-NEXT:        Branch relaxation pass
 ; GCN-O1-OPTS-NEXT:        Register Usage Information Collector Pass
 ; GCN-O1-OPTS-NEXT:        Live DEBUG_VALUE analysis
 ; GCN-O1-OPTS-NEXT:        Machine Sanitizer Binary Metadata
+; GCN-O1-OPTS-NEXT:        Lazy Machine Block Frequency Analysis
+; GCN-O1-OPTS-NEXT:        Machine Optimization Remark Emitter
+; GCN-O1-OPTS-NEXT:        Stack Frame Layout Analysis
 ; GCN-O1-OPTS-NEXT:    Function register usage analysis
 ; GCN-O1-OPTS-NEXT:    FunctionPass Manager
 ; GCN-O1-OPTS-NEXT:      Lazy Machine Block Frequency Analysis
 ; GCN-O1-OPTS-NEXT:      Machine Optimization Remark Emitter
 ; GCN-O1-OPTS-NEXT:      AMDGPU Assembly Printer
 ; GCN-O1-OPTS-NEXT:      Free MachineFunction
 ; GCN-O1-OPTS-NEXT:Pass Arguments:  -domtree
 ; GCN-O1-OPTS-NEXT:  FunctionPass Manager

 ; GCN-O2-NEXT:        SI peephole optimizations
 ; GCN-O2-NEXT:        Post RA hazard recognizer
 ; GCN-O2-NEXT:        Release VGPRs
 ; GCN-O2-NEXT:        AMDGPU Insert Delay ALU
 ; GCN-O2-NEXT:        Branch relaxation pass
 ; GCN-O2-NEXT:        Register Usage Information Collector Pass
 ; GCN-O2-NEXT:        Live DEBUG_VALUE analysis
 ; GCN-O2-NEXT:        Machine Sanitizer Binary Metadata
+; GCN-O2-NEXT:        Lazy Machine Block Frequency Analysis
+; GCN-O2-NEXT:        Machine Optimization Remark Emitter
+; GCN-O2-NEXT:        Stack Frame Layout Analysis
 ; GCN-O2-NEXT:    Function register usage analysis
 ; GCN-O2-NEXT:    FunctionPass Manager
 ; GCN-O2-NEXT:      Lazy Machine Block Frequency Analysis
 ; GCN-O2-NEXT:      Machine Optimization Remark Emitter
 ; GCN-O2-NEXT:      AMDGPU Assembly Printer
 ; GCN-O2-NEXT:      Free MachineFunction
 ; GCN-O2-NEXT:Pass Arguments:  -domtree
 ; GCN-O2-NEXT:  FunctionPass Manager

 ; GCN-O3-NEXT:        SI peephole optimizations
 ; GCN-O3-NEXT:        Post RA hazard recognizer
 ; GCN-O3-NEXT:        Release VGPRs
 ; GCN-O3-NEXT:        AMDGPU Insert Delay ALU
 ; GCN-O3-NEXT:        Branch relaxation pass
 ; GCN-O3-NEXT:        Register Usage Information Collector Pass
 ; GCN-O3-NEXT:        Live DEBUG_VALUE analysis
 ; GCN-O3-NEXT:        Machine Sanitizer Binary Metadata
+; GCN-O3-NEXT:        Lazy Machine Block Frequency Analysis
+; GCN-O3-NEXT:        Machine Optimization Remark Emitter
+; GCN-O3-NEXT:        Stack Frame Layout Analysis
 ; GCN-O3-NEXT:    Function register usage analysis
 ; GCN-O3-NEXT:    FunctionPass Manager
 ; GCN-O3-NEXT:      Lazy Machine Block Frequency Analysis
 ; GCN-O3-NEXT:      Machine Optimization Remark Emitter
 ; GCN-O3-NEXT:      AMDGPU Assembly Printer
 ; GCN-O3-NEXT:      Free MachineFunction
 ; GCN-O3-NEXT:Pass Arguments:  -domtree
 ; GCN-O3-NEXT:  FunctionPass Manager
 ; GCN-O3-NEXT:    Dominator Tree Construction
 
 define void @empty() {
   ret void
 }

llvm/test/CodeGen/ARM/O3-pipeline.ll

 ; CHECK-NEXT:      ARM block placement
 ; CHECK-NEXT:      optimise barriers pass
 ; CHECK-NEXT:      Contiguously Lay Out Funclets
 ; CHECK-NEXT:      StackMap Liveness Analysis
 ; CHECK-NEXT:      Live DEBUG_VALUE analysis
 ; CHECK-NEXT:      Machine Sanitizer Binary Metadata
 ; CHECK-NEXT:    Machine Outliner
 ; CHECK-NEXT:    FunctionPass Manager
+; CHECK-NEXT:      Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:      Machine Optimization Remark Emitter
+; CHECK-NEXT:      Stack Frame Layout Analysis
 ; CHECK-NEXT:      ReachingDefAnalysis
 ; CHECK-NEXT:      ARM fix for Cortex-A57 AES Erratum 1742098
 ; CHECK-NEXT:      ARM Branch Targets
 ; CHECK-NEXT:      MachineDominator Tree Construction
 ; CHECK-NEXT:      ARM constant island placement and branch shortening pass
 ; CHECK-NEXT:      MachineDominator Tree Construction
 ; CHECK-NEXT:      Machine Natural Loop Construction
 ; CHECK-NEXT:      ReachingDefAnalysis
 ; CHECK-NEXT:      ARM Low Overhead Loops pass
 ; CHECK-NEXT:      Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:      Machine Optimization Remark Emitter
 ; CHECK-NEXT:      ARM Assembly Printer
 ; CHECK-NEXT:      Free MachineFunction

llvm/test/CodeGen/ARM/stack-frame-layout-remarks.ll

+; Test remark output for stack-frame-layout
+
+; ensure basic output works
+; RUN: llc -mtriple=arm-eabi -O1 -pass-remarks-analysis=stack-frame-layout < %s 2>&1 >/dev/null | FileCheck %s
+
+; check additional slots are displayed when stack is not optimized
+; RUN: llc -mtriple=arm-eabi -O0  -pass-remarks-analysis=stack-frame-layout < %s 2>&1 >/dev/null | FileCheck %s --check-prefix=NO_COLORING
+
+; check more complex cases
+; RUN: llc %s  -pass-remarks-analysis=stack-frame-layout -o /dev/null --march=arm -mcpu=cortex-m1 2>&1 | FileCheck %s --check-prefix=BOTH --check-prefix=DEBUG
+
+; check output without debug info
+; RUN: opt %s -passes=strip -S | llc   -pass-remarks-analysis=stack-frame-layout -o /dev/null --march=arm -mcpu=cortex-m1 2>&1 | FileCheck %s --check-prefix=BOTH --check-prefix=STRIPPED
+
+target triple = "x86_64-unknown-linux-gnu"
+
+@.str = private unnamed_addr constant [4 x i8] c"%s\0A\00", align 1
+declare i32 @printf(ptr, ...)
+
+; CHECK: Function: stackSizeWarning
+; CHECK: [SP-4]{{.*}}Spill{{.*}}4{{.*}}4
+; CHECK: [SP-96]{{.*}}16{{.*}}80
+; CHECK:    buffer @ frame-diags.c:30
+; NO_COLORING: [SP-176]{{.*}}16{{.*}}80
+; CHECK:    buffer2 @ frame-diags.c:33
+
+; BOTH: Function: stackSizeWarning
+; BOTH: [SP-4]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-8]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-12]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-16]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-96]{{.*}}16{{.*}}80
+; DEBUG: buffer @ frame-diags.c:30
+; STRIPPED-NOT: buffer @ frame-diags.c:30
+; BOTH: [SP-176]{{.*}}16{{.*}}80
+; DEBUG: buffer2 @ frame-diags.c:33
+; STRIPPED-NOT: buffer2 @ frame-diags.c:33
+define void @stackSizeWarning() {
+entry:
+  %buffer = alloca [80 x i8], align 16
+  %buffer2 = alloca [80 x i8], align 16
+  call void @llvm.dbg.declare(metadata ptr %buffer, metadata !25, metadata !DIExpression()), !dbg !39
+  call void @llvm.dbg.declare(metadata ptr %buffer2, metadata !31, metadata !DIExpression()), !dbg !40
+  ret void
+}
+
+; Function Attrs: nocallback nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #0
+
+; BOTH: Function: cleanup_array
+; BOTH:  [SP-8]{{.+}}8{{.+}}4
+; DEBUG: a @ dot.c:13
+; STRIPPED-NOT: a @ dot.c:13
+define void @cleanup_array(ptr %0) #1 {
+  %2 = alloca ptr, align 8
+  store ptr %0, ptr %2, align 8
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !41, metadata !DIExpression()), !dbg !46
+  ret void
+}
+
+; BOTH: Function: cleanup_result
+; BOTH:  [SP-8]{{.+}}8{{.+}}4
+; DEBUG: res @ dot.c:21
+; STRIPPED-NOT: res @ dot.c:21
+define void @cleanup_result(ptr %0) #1 {
+  %2 = alloca ptr, align 8
+  store ptr %0, ptr %2, align 8
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !47, metadata !DIExpression()), !dbg !51
+  ret void
+}
+
+; BOTH: Function: do_work
+; BOTH:  [SP-4]{{.+}}4{{.+}}4
+; BOTH:  [SP-8]{{.+}}8{{.+}}4
+; DEBUG: A @ dot.c:32
+; STRIPPED-NOT: A @ dot.c:32
+; BOTH:  [SP-16]{{.+}}8{{.+}}4
+; DEBUG: B @ dot.c:32
+; STRIPPED-NOT: B @ dot.c:32
+; BOTH:  [SP-24]{{.+}}8{{.+}}4
+; DEBUG: out @ dot.c:32
+; STRIPPED-NOT: out @ dot.c:32
+; BOTH:  [SP-28]{{.+}}4{{.+}}4
+; DEBUG: len @ dot.c:37
+; STRIPPED-NOT: len @ dot.c:37
+; BOTH:  [SP-32]{{.+}}8{{.+}}4
+; DEBUG: AB @ dot.c:38
+; STRIPPED-NOT: AB @ dot.c:38
+; BOTH:  [SP-36]{{.+}}4{{.+}}4
+; DEBUG: sum @ dot.c:54
+; STRIPPED-NOT: sum @ dot.c:54
+; BOTH:  [SP-40]{{.+}}4{{.+}}4
+; DEBUG: i @ dot.c:55
+; STRIPPED-NOT: i @ dot.c:55
+define i32 @do_work(ptr %0, ptr %1, ptr %2) #1 {
+  %4 = alloca i32, align 4
+  %5 = alloca ptr, align 8
+  %6 = alloca ptr, align 8
+  %7 = alloca ptr, align 8
+  %8 = alloca i32, align 4
+  %9 = alloca ptr, align 8
+  %10 = alloca i32, align 4
+  %11 = alloca i32, align 4
+  store ptr %0, ptr %5, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !52, metadata !DIExpression()), !dbg !56
+  call void @llvm.dbg.declare(metadata ptr %6, metadata !57, metadata !DIExpression()), !dbg !58
+  store ptr %2, ptr %7, align 8
+  call void @llvm.dbg.declare(metadata ptr %7, metadata !59, metadata !DIExpression()), !dbg !60
+  call void @llvm.dbg.declare(metadata ptr %8, metadata !61, metadata !DIExpression()), !dbg !63
+  call void @llvm.dbg.declare(metadata ptr %9, metadata !64, metadata !DIExpression()), !dbg !65
+  store ptr null, ptr %9, align 8
+  store ptr null, ptr null, align 8
+  store i32 0, ptr %9, align 8
+  %12 = load i32, ptr %8, align 4
+  store i32 %12, ptr null, align 8
+  call void @llvm.dbg.declare(metadata ptr %10, metadata !66, metadata !DIExpression()), !dbg !67
+  call void @llvm.dbg.declare(metadata ptr %11, metadata !68, metadata !DIExpression()), !dbg !70
+  store i32 0, ptr %11, align 4
+  br label %13
+
+13:                                               ; preds = %16, %3
+  %14 = load i32, ptr %11, align 4
+  %15 = icmp slt i32 %14, 0
+  br i1 %15, label %16, label %18
+
+16:                                               ; preds = %13
+  %17 = load i32, ptr %6, align 4
+  store i32 %17, ptr null, align 4
+  br label %13
+
+18:                                               ; preds = %13
+  store i32 0, ptr %4, align 4
+  ret i32 0
+}
+
+; BOTH: Function: gen_array
+; BOTH:  [SP-8]{{.+}}8{{.+}}4
+; BOTH:  [SP-12]{{.+}}4{{.+}}4
+; DEBUG: size @ dot.c:62
+; STRIPPED-NOT: size @ dot.c:65
+; BOTH:  [SP-16]{{.+}}8{{.+}}4
+; DEBUG: res @ dot.c:65
+; STRIPPED-NOT: res @ dot.c:65
+; BOTH:  [SP-20]{{.+}}4{{.*}}4
+; DEBUG: i @ dot.c:69
+; STRIPPED-NOT: i @ dot.c:69
+define ptr @gen_array(i32 %0) #1 {
+  %2 = alloca ptr, align 8
+  %3 = alloca i32, align 4
+  %4 = alloca ptr, align 8
+  %5 = alloca i32, align 4
+  store i32 %0, ptr %3, align 4
+  call void @llvm.dbg.declare(metadata ptr %3, metadata !71, metadata !DIExpression()), !dbg !75
+  call void @llvm.dbg.declare(metadata ptr %4, metadata !76, metadata !DIExpression()), !dbg !77
+  store ptr null, ptr %4, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !78, metadata !DIExpression()), !dbg !80
+  store i32 0, ptr %5, align 4
+  ret ptr null
+}
+
+
+; BOTH: Function: caller
+; BOTH: [SP-4]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-8]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-12]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-16]{{.*}}Spill{{.*}}4{{.*}}4
+; BOTH: [SP-20]{{.*}}4{{.*}}4
+; BOTH: [SP-24]{{.*}}4{{.*}}4
+; DEBUG: size @ dot.c:77
+; STRIPPED-NOT: size @ dot.c:77
+; BOTH: [SP-32]{{.*}}8{{.*}}4
+; DEBUG: A @ dot.c:78
+; STRIPPED-NOT: A @ dot.c:78
+; BOTH: [SP-40]{{.*}}8{{.*}}4
+; DEBUG: B @ dot.c:79
+; STRIPPED-NOT: B @ dot.c:79
+; BOTH: [SP-48]{{.*}}8{{.*}}4
+; DEBUG: res @ dot.c:80
+; STRIPPED-NOT: res @ dot.c:80
+; BOTH: [SP-52]{{.*}}4{{.*}}4
+; DEBUG: ret @ dot.c:81
+; STRIPPED-NOT: ret @ dot.c:81
+; BOTH: [SP-56]{{.*}}4{{.*}}4
+; DEBUG: err @ dot.c:83
+; STRIPPED-NOT: err @ dot.c:83
+define i32 @caller() #1 {
+  %1 = alloca i32, align 4
+  %2 = alloca i32, align 4
+  %3 = alloca ptr, align 8
+  %4 = alloca ptr, align 8
+  %5 = alloca ptr, align 8
+  %6 = alloca i32, align 4
+  %7 = alloca i32, align 4
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !81, metadata !DIExpression()), !dbg !85
+  call void @llvm.dbg.declare(metadata ptr %3, metadata !86, metadata !DIExpression()), !dbg !87
+  call void @llvm.dbg.declare(metadata ptr %4, metadata !88, metadata !DIExpression()), !dbg !89
+  store ptr null, ptr %4, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !90, metadata !DIExpression()), !dbg !91
+  call void @llvm.dbg.declare(metadata ptr %6, metadata !92, metadata !DIExpression()), !dbg !93
+  call void @llvm.dbg.declare(metadata ptr %7, metadata !94, metadata !DIExpression()), !dbg !95
+  %8 = call i32 @do_work(ptr %3, ptr null, ptr null)
+  store i32 0, ptr %6, align 4
+  store i32 0, ptr %1, align 4
+  call void @cleanup_result(ptr %5)
+  ret i32 0
+}
+
+; test29b: An array of [5 x i8] and a requested ssp-buffer-size of 5.
+; Requires protector.
+; Function Attrs: ssp stack-protector-buffer-size=5
+; BOTH: Function: test29b
+; BOTH:  [SP-4]{{.+}}Spill{{.*}}4{{.+}}4
+; BOTH:  [SP-8]{{.+}}Spill{{.*}}4{{.+}}4
+; BOTH:  [SP-12]{{.+}}Protector{{.*}}4{{.+}}4
+; BOTH:  [SP-20]{{.+}}4{{.+}}5
+define i32 @test29b() #2 {
+entry:
+  %test = alloca [5 x i8], align 1
+  %call = call i32 (ptr, ...) @printf(ptr @.str, ptr %test)
+  ret i32 %call
+}
+
+
+; uselistorder directives
+uselistorder ptr @llvm.dbg.declare, { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 18 }
+
+attributes #0 = { nocallback nofree nosync nounwind readnone speculatable willreturn }
+attributes #1 = { "frame-pointer"="all" }
+attributes #2 = { ssp "stack-protector-buffer-size"="5" "frame-pointer"="all" }
+
+!llvm.dbg.cu = !{!0, !2}
+!llvm.module.flags = !{!18, !19, !20, !21, !22, !23, !24}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "frame-diags.c", directory: "")
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, retainedTypes: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "dot.c", directory: "")
+!4 = !{!5, !6, !10, !13}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: null, size: 64)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64)
+!7 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Array", file: !3, line: 3, size: 128, elements: !8)
+!8 = !{!9, !12}
+!9 = !DIDerivedType(tag: DW_TAG_member, name: "data", scope: !7, file: !3, line: 4, baseType: !10, size: 64)
+!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
+!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!12 = !DIDerivedType(tag: DW_TAG_member, name: "size", scope: !7, file: !3, line: 5, baseType: !11, size: 32, offset: 64)
+!13 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !14, size: 64)
+!14 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Result", file: !3, line: 8, size: 128, elements: !15)
+!15 = !{!16, !17}
+!16 = !DIDerivedType(tag: DW_TAG_member, name: "data", scope: !14, file: !3, line: 9, baseType: !6, size: 64)
+!17 = !DIDerivedType(tag: DW_TAG_member, name: "sum", scope: !14, file: !3, line: 10, baseType: !11, size: 32, offset: 64)
+!18 = !{i32 7, !"Dwarf Version", i32 5}
+!19 = !{i32 2, !"Debug Info Version", i32 3}
+!20 = !{i32 1, !"wchar_size", i32 4}
+!21 = !{i32 8, !"PIC Level", i32 2}
+!22 = !{i32 7, !"PIE Level", i32 2}
+!23 = !{i32 7, !"uwtable", i32 2}
+!24 = !{i32 7, !"frame-pointer", i32 2}
+!25 = !DILocalVariable(name: "buffer", scope: !26, file: !1, line: 30, type: !32)
+!26 = distinct !DILexicalBlock(scope: !27, file: !1, line: 29, column: 3)
+!27 = distinct !DISubprogram(name: "stackSizeWarning", scope: !1, file: !1, line: 28, type: !28, scopeLine: 28, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !30)
+!28 = !DISubroutineType(types: !29)
+!29 = !{null}
+!30 = !{!25, !31, !36, !37}
+!31 = !DILocalVariable(name: "buffer2", scope: !27, file: !1, line: 33, type: !32)
+!32 = !DICompositeType(tag: DW_TAG_array_type, baseType: !33, size: 640, elements: !34)
+!33 = !DIBasicType(name: "char", size: 8, encoding: DW_ATE_signed_char)
+!34 = !{!35}
+!35 = !DISubrange(count: 80)
+!36 = !DILocalVariable(name: "a", scope: !27, file: !1, line: 34, type: !11)
+!37 = !DILocalVariable(name: "b", scope: !27, file: !1, line: 35, type: !38)
+!38 = !DIBasicType(name: "long", size: 64, encoding: DW_ATE_signed)
+!39 = !DILocation(line: 30, column: 10, scope: !26)
+!40 = !DILocation(line: 33, column: 8, scope: !27)
+!41 = !DILocalVariable(name: "a", arg: 1, scope: !42, file: !3, line: 13, type: !6)
+!42 = distinct !DISubprogram(name: "cleanup_array", scope: !3, file: !3, line: 13, type: !43, scopeLine: 13, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!43 = !DISubroutineType(types: !44)
+!44 = !{null, !6}
+!45 = !{}
+!46 = !DILocation(line: 13, column: 34, scope: !42)
+!47 = !DILocalVariable(name: "res", arg: 1, scope: !48, file: !3, line: 21, type: !13)
+!48 = distinct !DISubprogram(name: "cleanup_result", scope: !3, file: !3, line: 21, type: !49, scopeLine: 21, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!49 = !DISubroutineType(types: !50)
+!50 = !{null, !13}
+!51 = !DILocation(line: 21, column: 36, scope: !48)
+!52 = !DILocalVariable(name: "A", arg: 1, scope: !53, file: !3, line: 32, type: !6)
+!53 = distinct !DISubprogram(name: "do_work", scope: !3, file: !3, line: 32, type: !54, scopeLine: 32, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!54 = !DISubroutineType(types: !55)
+!55 = !{!11, !6, !6, !13}
+!56 = !DILocation(line: 32, column: 27, scope: !53)
+!57 = !DILocalVariable(name: "B", arg: 2, scope: !53, file: !3, line: 32, type: !6)
+!58 = !DILocation(line: 32, column: 44, scope: !53)
+!59 = !DILocalVariable(name: "out", arg: 3, scope: !53, file: !3, line: 32, type: !13)
+!60 = !DILocation(line: 32, column: 62, scope: !53)
+!61 = !DILocalVariable(name: "len", scope: !53, file: !3, line: 37, type: !62)
+!62 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !11)
+!63 = !DILocation(line: 37, column: 13, scope: !53)
+!64 = !DILocalVariable(name: "AB", scope: !53, file: !3, line: 38, type: !6)
+!65 = !DILocation(line: 38, column: 17, scope: !53)
+!66 = !DILocalVariable(name: "sum", scope: !53, file: !3, line: 54, type: !11)
+!67 = !DILocation(line: 54, column: 7, scope: !53)
+!68 = !DILocalVariable(name: "i", scope: !69, file: !3, line: 55, type: !11)
+!69 = distinct !DILexicalBlock(scope: !53, file: !3, line: 55, column: 3)
+!70 = !DILocation(line: 55, column: 12, scope: !69)
+!71 = !DILocalVariable(name: "size", arg: 1, scope: !72, file: !3, line: 62, type: !11)
+!72 = distinct !DISubprogram(name: "gen_array", scope: !3, file: !3, line: 62, type: !73, scopeLine: 62, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!73 = !DISubroutineType(types: !74)
+!74 = !{!6, !11}
+!75 = !DILocation(line: 62, column: 29, scope: !72)
+!76 = !DILocalVariable(name: "res", scope: !72, file: !3, line: 65, type: !6)
+!77 = !DILocation(line: 65, column: 17, scope: !72)
+!78 = !DILocalVariable(name: "i", scope: !79, file: !3, line: 69, type: !11)
+!79 = distinct !DILexicalBlock(scope: !72, file: !3, line: 69, column: 3)
+!80 = !DILocation(line: 69, column: 12, scope: !79)
+!81 = !DILocalVariable(name: "size", scope: !82, file: !3, line: 77, type: !62)
+!82 = distinct !DISubprogram(name: "caller", scope: !3, file: !3, line: 76, type: !83, scopeLine: 76, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!83 = !DISubroutineType(types: !84)
+!84 = !{!11}
+!85 = !DILocation(line: 77, column: 13, scope: !82)
+!86 = !DILocalVariable(name: "A", scope: !82, file: !3, line: 78, type: !6)
+!87 = !DILocation(line: 78, column: 17, scope: !82)
+!88 = !DILocalVariable(name: "B", scope: !82, file: !3, line: 79, type: !6)
+!89 = !DILocation(line: 79, column: 17, scope: !82)
+!90 = !DILocalVariable(name: "res", scope: !82, file: !3, line: 80, type: !13)
+!91 = !DILocation(line: 80, column: 18, scope: !82)
+!92 = !DILocalVariable(name: "ret", scope: !82, file: !3, line: 81, type: !11)
+!93 = !DILocation(line: 81, column: 7, scope: !82)
+!94 = !DILocalVariable(name: "err", scope: !82, file: !3, line: 83, type: !11)
+!95 = !DILocation(line: 83, column: 7, scope: !82)

llvm/test/CodeGen/Generic/llc-start-stop.ll

 ; NVPTX customizes the list of passes so the test cannot find what it expects
 ; XFAIL: target=nvptx{{.*}}
 
 ; Note: -verify-machineinstrs is used in order to make this test compatible with EXPENSIVE_CHECKS.
 ; RUN: llc < %s -debug-pass=Structure -stop-after=loop-reduce -verify-machineinstrs -o /dev/null 2>&1 \
 ; RUN:   | FileCheck %s -check-prefix=STOP-AFTER
 ; STOP-AFTER: -loop-reduce
 ; STOP-AFTER: Dominator Tree Construction
 ; STOP-AFTER: Loop Strength Reduction
 ; STOP-AFTER-NEXT: Verify generated machine code
+; STOP-AFTER-NEXT: Lazy Machine Block Frequency Analysis
+; STOP-AFTER-NEXT: Machine Optimization Remark Emitter
+; STOP-AFTER-NEXT: Stack Frame Layout Analysis
 ; STOP-AFTER-NEXT: MIR Printing Pass
 
 ; RUN: llc < %s -debug-pass=Structure -stop-before=loop-reduce -o /dev/null 2>&1 | FileCheck %s -check-prefix=STOP-BEFORE
 ; STOP-BEFORE-NOT: -loop-reduce
 ; STOP-BEFORE: Dominator Tree Construction
 ; STOP-BEFORE-NOT: Loop Strength Reduction
 
 ; RUN: llc < %s -debug-pass=Structure -start-after=loop-reduce -o /dev/null 2>&1 | FileCheck %s -check-prefix=START-AFTER

llvm/test/CodeGen/LoongArch/O0-pipeline.ll

 ; CHECK-NEXT:       Insert fentry calls
 ; CHECK-NEXT:       Insert XRay ops
 ; CHECK-NEXT:       Implement the 'patchable-function' attribute
 ; CHECK-NEXT:       Branch relaxation pass
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       LoongArch atomic pseudo instruction expansion pass
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       LoongArch Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction

llvm/test/CodeGen/LoongArch/opt-pipeline.ll

 ; CHECK-NEXT:       Insert fentry calls
 ; CHECK-NEXT:       Insert XRay ops
 ; CHECK-NEXT:       Implement the 'patchable-function' attribute
 ; CHECK-NEXT:       Branch relaxation pass
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       LoongArch atomic pseudo instruction expansion pass
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       LoongArch Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction

llvm/test/CodeGen/M68k/pipeline.ll

 ; CHECK-NEXT:      Implement the 'patchable-function' attribute
 ; CHECK-NEXT:      M68k MOVEM collapser pass
 ; CHECK-NEXT:      Contiguously Lay Out Funclets
 ; CHECK-NEXT:      StackMap Liveness Analysis
 ; CHECK-NEXT:      Live DEBUG_VALUE analysis
 ; CHECK-NEXT:      Machine Sanitizer Binary Metadata
 ; CHECK-NEXT:      Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:      Machine Optimization Remark Emitter
+; CHECK-NEXT:      Stack Frame Layout Analysis
 ; CHECK-NEXT:      M68k Assembly Printer
 ; CHECK-NEXT:      Free MachineFunction

llvm/test/CodeGen/PowerPC/O0-pipeline.ll

 ; CHECK-NEXT:       Insert XRay ops
 ; CHECK-NEXT:       Implement the 'patchable-function' attribute
 ; CHECK-NEXT:       PowerPC Pre-Emit Peephole
 ; CHECK-NEXT:       PowerPC Expand ISEL Generation
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       PowerPC Expand Atomic
 ; CHECK-NEXT:       PowerPC Branch Selector
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       Linux PPC Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction
 
 define void @f() {
   ret void
 }

llvm/test/CodeGen/PowerPC/O3-pipeline.ll

 ; CHECK-NEXT:       Implement the 'patchable-function' attribute
 ; CHECK-NEXT:       PowerPC Pre-Emit Peephole
 ; CHECK-NEXT:       PowerPC Expand ISEL Generation
 ; CHECK-NEXT:       PowerPC Early-Return Creation
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       PowerPC Expand Atomic
 ; CHECK-NEXT:       PowerPC Branch Selector
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       Linux PPC Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction
 
 define void @f() {
   ret void
 }

llvm/test/CodeGen/RISCV/O0-pipeline.ll

 ; CHECK-NEXT:       Insert XRay ops
 ; CHECK-NEXT:       Implement the 'patchable-function' attribute
 ; CHECK-NEXT:       Branch relaxation pass
 ; CHECK-NEXT:       RISCV Make Compressible
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       RISCV pseudo instruction expansion pass
 ; CHECK-NEXT:       RISCV atomic pseudo instruction expansion pass
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       RISCV Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction

llvm/test/CodeGen/RISCV/O3-pipeline.ll

 ; CHECK-NEXT:       Branch relaxation pass
 ; CHECK-NEXT:       RISCV Make Compressible
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
 ; CHECK-NEXT:     Machine Outliner
 ; CHECK-NEXT:     FunctionPass Manager
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       RISCV pseudo instruction expansion pass
 ; CHECK-NEXT:       RISCV atomic pseudo instruction expansion pass
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       RISCV Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction

llvm/test/CodeGen/X86/O0-pipeline.ll

 ; CHECK-NEXT:       Compressing EVEX instrs to VEX encoding when possibl
 ; CHECK-NEXT:       X86 Discriminate Memory Operands
 ; CHECK-NEXT:       X86 Insert Cache Prefetches
 ; CHECK-NEXT:       X86 insert wait instruction
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       X86 Speculative Execution Side Effect Suppression
 ; CHECK-NEXT:       X86 Indirect Thunks
 ; CHECK-NEXT:       X86 Return Thunks
 ; CHECK-NEXT:       Check CFA info and insert CFI instructions if needed
 ; CHECK-NEXT:       X86 Load Value Injection (LVI) Ret-Hardening
 ; CHECK-NEXT:       Pseudo Probe Inserter
 ; CHECK-NEXT:       Unpack machine instruction bundles
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
 ; CHECK-NEXT:       Machine Optimization Remark Emitter
 ; CHECK-NEXT:       X86 Assembly Printer
 ; CHECK-NEXT:       Free MachineFunction
 
 define void @f() {
   ret void
 }

llvm/test/CodeGen/X86/opt-pipeline.ll

 ; CHECK-NEXT:       Compressing EVEX instrs to VEX encoding when possible
 ; CHECK-NEXT:       X86 Discriminate Memory Operands
 ; CHECK-NEXT:       X86 Insert Cache Prefetches
 ; CHECK-NEXT:       X86 insert wait instruction
 ; CHECK-NEXT:       Contiguously Lay Out Funclets
 ; CHECK-NEXT:       StackMap Liveness Analysis
 ; CHECK-NEXT:       Live DEBUG_VALUE analysis
 ; CHECK-NEXT:       Machine Sanitizer Binary Metadata
+; CHECK-NEXT:       Lazy Machine Block Frequency Analysis
+; CHECK-NEXT:       Machine Optimization Remark Emitter
+; CHECK-NEXT:       Stack Frame Layout Analysis
 ; CHECK-NEXT:       X86 Speculative Execution Side Effect Suppression
 ; CHECK-NEXT:       X86 Indirect Thunks
 ; CHECK-NEXT:       X86 Return Thunks
 ; CHECK-NEXT:       Check CFA info and insert CFI instructions if needed
 ; CHECK-NEXT:       X86 Load Value Injection (LVI) Ret-Hardening
 ; CHECK-NEXT:       Pseudo Probe Inserter
 ; CHECK-NEXT:       Unpack machine instruction bundles
 ; CHECK-NEXT:       Lazy Machine Block Frequency Analysis

llvm/test/CodeGen/X86/stack-frame-layout-remarks.ll

+; Test remark output for stack-frame-layout
+
+; ensure basic output works
+; RUN: llc -mcpu=corei7 -O1 -pass-remarks-analysis=stack-frame-layout < %s 2>&1 >/dev/null | FileCheck %s
+
+; check additional slots are displayed when stack is not optimized
+; RUN: llc -mcpu=corei7 -O0 -pass-remarks-analysis=stack-frame-layout < %s 2>&1 >/dev/null | FileCheck %s --check-prefix=NO_COLORING
+
+; check more complex cases
+; RUN: llc %s -pass-remarks-analysis=stack-frame-layout -o /dev/null --march=x86 -mcpu=i386 2>&1 | FileCheck %s --check-prefix=BOTH --check-prefix=DEBUG
+
+; check output without debug info
+; RUN: opt %s -passes=strip -S | llc  -pass-remarks-analysis=stack-frame-layout -o /dev/null --march=x86 -mcpu=i386 2>&1 | FileCheck %s --check-prefix=BOTH --check-prefix=STRIPPED
+
+target triple = "x86_64-unknown-linux-gnu"
+
+@.str = private unnamed_addr constant [4 x i8] c"%s\0A\00", align 1
+declare i32 @printf(ptr, ...)
+
+; CHECK: Function: stackSizeWarning
+; CHECK: Offset: [SP-88], Type: Variable, Align: 16, Size: 80
+; CHECK:    buffer @ frame-diags.c:30
+; NO_COLORING: Offset: [SP-168], Type: Variable, Align: 16, Size: 80
+; CHECK:    buffer2 @ frame-diags.c:33
+define void @stackSizeWarning() {
+entry:
+  %buffer = alloca [80 x i8], align 16
+  %buffer2 = alloca [80 x i8], align 16
+  call void @llvm.dbg.declare(metadata ptr %buffer, metadata !25, metadata !DIExpression()), !dbg !39
+  call void @llvm.dbg.declare(metadata ptr %buffer2, metadata !31, metadata !DIExpression()), !dbg !40
+  ret void
+}
+
+; Function Attrs: nocallback nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #0
+
+; BOTH: Function: cleanup_array
+; BOTH-Next:  Offset: [SP+4], Type: Protector, Align: 16, Size: 4
+; DEBUG: a @ dot.c:13
+; STRIPPED-NOT: a @ dot.c:13
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+define void @cleanup_array(ptr %0) #1 {
+  %2 = alloca ptr, align 8
+  store ptr %0, ptr %2, align 8
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !41, metadata !DIExpression()), !dbg !46
+  ret void
+}
+
+; BOTH: Function: cleanup_result
+; BOTH:  Offset: [SP+4], Type: Protector, Align: 16, Size: 4
+; DEBUG: res @ dot.c:21
+; STRIPPED-NOT: res @ dot.c:21
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+define void @cleanup_result(ptr %0) #1 {
+  %2 = alloca ptr, align 8
+  store ptr %0, ptr %2, align 8
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !47, metadata !DIExpression()), !dbg !51
+  ret void
+}
+
+; BOTH: Function: do_work
+; BOTH:  Offset: [SP+12], Type: Variable, Align: 8, Size: 4
+; DEBUG: out @ dot.c:32
+; STRIPPED-NOT: out @ dot.c:32
+; BOTH:  Offset: [SP+8], Type: Variable, Align: 4, Size: 4
+; BOTH:  Offset: [SP+4], Type: Protector, Align: 16, Size: 4
+; DEBUG: A @ dot.c:32
+; STRIPPED-NOT: A @ dot.c:32
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+; BOTH:  Offset: [SP-12], Type: Variable, Align: 8, Size: 4
+; DEBUG: AB @ dot.c:38
+; STRIPPED-NOT: AB @ dot.c:38
+; BOTH:  Offset: [SP-16], Type: Variable, Align: 4, Size: 4
+; DEBUG: i @ dot.c:55
+; STRIPPED-NOT: i @ dot.c:55
+; BOTH:  Offset: [SP-20], Type: Variable, Align: 8, Size: 4
+; DEBUG: B @ dot.c:32
+; STRIPPED-NOT: B @ dot.c:32
+; BOTH:  Offset: [SP-24], Type: Variable, Align: 4, Size: 4
+; DEBUG: len @ dot.c:37
+; STRIPPED-NOT: len @ dot.c:37
+; BOTH:  Offset: [SP-28], Type: Variable, Align: 4, Size: 4
+; BOTH:  Offset: [SP-32], Type: Variable, Align: 4, Size: 4
+; DEBUG: sum @ dot.c:54
+; STRIPPED-NOT: sum @ dot.c:54
+define i32 @do_work(ptr %0, ptr %1, ptr %2) #2 {
+  %4 = alloca i32, align 4
+  %5 = alloca ptr, align 8
+  %6 = alloca ptr, align 8
+  %7 = alloca ptr, align 8
+  %8 = alloca i32, align 4
+  %9 = alloca ptr, align 8
+  %10 = alloca i32, align 4
+  %11 = alloca i32, align 4
+  store ptr %0, ptr %5, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !52, metadata !DIExpression()), !dbg !56
+  call void @llvm.dbg.declare(metadata ptr %6, metadata !57, metadata !DIExpression()), !dbg !58
+  store ptr %2, ptr %7, align 8
+  call void @llvm.dbg.declare(metadata ptr %7, metadata !59, metadata !DIExpression()), !dbg !60
+  call void @llvm.dbg.declare(metadata ptr %8, metadata !61, metadata !DIExpression()), !dbg !63
+  call void @llvm.dbg.declare(metadata ptr %9, metadata !64, metadata !DIExpression()), !dbg !65
+  store ptr null, ptr %9, align 8
+  store ptr null, ptr null, align 8
+  store i32 0, ptr %9, align 8
+  %12 = load i32, ptr %8, align 4
+  store i32 %12, ptr null, align 8
+  call void @llvm.dbg.declare(metadata ptr %10, metadata !66, metadata !DIExpression()), !dbg !67
+  call void @llvm.dbg.declare(metadata ptr %11, metadata !68, metadata !DIExpression()), !dbg !70
+  store i32 0, ptr %11, align 4
+  br label %13
+
+13:                                               ; preds = %16, %3
+  %14 = load i32, ptr %11, align 4
+  %15 = icmp slt i32 %14, 0
+  br i1 %15, label %16, label %18
+
+16:                                               ; preds = %13
+  %17 = load i32, ptr %6, align 4
+  store i32 %17, ptr null, align 4
+  br label %13
+
+18:                                               ; preds = %13
+  store i32 0, ptr %4, align 4
+  ret i32 0
+}
+
+; BOTH: Function: gen_array
+; BOTH:  Offset: [SP+4], Type: Protector, Align: 16, Size: 4
+; DEBUG: size @ dot.c:62
+; STRIPPED-NOT: size @ dot.c:62
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+; BOTH:  Offset: [SP-12], Type: Variable, Align: 8, Size: 4
+; DEBUG: res @ dot.c:65
+; STRIPPED-NOT: res @ dot.c:65
+; BOTH:  Offset: [SP-16], Type: Variable, Align: 4, Size: 4
+; DEBUG: i @ dot.c:69
+; STRIPPED-NOT: i @ dot.c:69
+; BOTH:  Offset: [SP-20], Type: Variable, Align: 8, Size: 4
+define ptr @gen_array(i32 %0) #1 {
+  %2 = alloca ptr, align 8
+  %3 = alloca i32, align 4
+  %4 = alloca ptr, align 8
+  %5 = alloca i32, align 4
+  store i32 %0, ptr %3, align 4
+  call void @llvm.dbg.declare(metadata ptr %3, metadata !71, metadata !DIExpression()), !dbg !75
+  call void @llvm.dbg.declare(metadata ptr %4, metadata !76, metadata !DIExpression()), !dbg !77
+  store ptr null, ptr %4, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !78, metadata !DIExpression()), !dbg !80
+  store i32 0, ptr %5, align 4
+  ret ptr null
+}
+
+; BOTH: Function: caller
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+; BOTH:  Offset: [SP-12], Type: Variable, Align: 8, Size: 4
+; DEBUG: res @ dot.c:80
+; STRIPPED-NOT: res @ dot.c:80
+; BOTH:  Offset: [SP-20], Type: Variable, Align: 8, Size: 4
+; DEBUG: B @ dot.c:79
+; STRIPPED-NOT: B @ dot.c:79
+; BOTH:  Offset: [SP-28], Type: Variable, Align: 8, Size: 4
+; DEBUG: A @ dot.c:78
+; STRIPPED-NOT: A @ dot.c:78
+; BOTH:  Offset: [SP-32], Type: Variable, Align: 4, Size: 4
+; DEBUG: ret @ dot.c:81
+; STRIPPED-NOT: ret @ dot.c:81
+; BOTH:  Offset: [SP-36], Type: Variable, Align: 4, Size: 4
+; BOTH:  Offset: [SP-40], Type: Variable, Align: 4, Size: 4
+; DEBUG: err @ dot.c:83
+; STRIPPED-NOT: err @ dot.c:83
+; BOTH:  Offset: [SP-44], Type: Variable, Align: 4, Size: 4
+; DEBUG:  size @ dot.c:77
+; STRIPPED-NOT: size @ dot.c:77
+define i32 @caller() #1 {
+  %1 = alloca i32, align 4
+  %2 = alloca i32, align 4
+  %3 = alloca ptr, align 8
+  %4 = alloca ptr, align 8
+  %5 = alloca ptr, align 8
+  %6 = alloca i32, align 4
+  %7 = alloca i32, align 4
+  call void @llvm.dbg.declare(metadata ptr %2, metadata !81, metadata !DIExpression()), !dbg !85
+  call void @llvm.dbg.declare(metadata ptr %3, metadata !86, metadata !DIExpression()), !dbg !87
+  call void @llvm.dbg.declare(metadata ptr %4, metadata !88, metadata !DIExpression()), !dbg !89
+  store ptr null, ptr %4, align 8
+  call void @llvm.dbg.declare(metadata ptr %5, metadata !90, metadata !DIExpression()), !dbg !91
+  call void @llvm.dbg.declare(metadata ptr %6, metadata !92, metadata !DIExpression()), !dbg !93
+  call void @llvm.dbg.declare(metadata ptr %7, metadata !94, metadata !DIExpression()), !dbg !95
+  %8 = call i32 @do_work(ptr %3, ptr null, ptr null)
+  store i32 0, ptr %6, align 4
+  store i32 0, ptr %1, align 4
+  call void @cleanup_result(ptr %5)
+  ret i32 0
+}
+
+; test29b: An array of [5 x i8] and a requested ssp-buffer-size of 5.
+; Requires protector.
+; Function Attrs: ssp stack-protector-buffer-size=5
+; BOTH: Function: test29b
+; BOTH:  Offset: [SP-4], Type: Spill, Align: 8, Size: 4
+; BOTH:  Offset: [SP-8], Type: Protector, Align: 4, Size: 4
+; BOTH:  Offset: [SP-13], Type: Variable, Align: 1, Size: 5
+define i32 @test29b() #2 {
+entry:
+  %test = alloca [5 x i8], align 1
+  %call = call i32 (ptr, ...) @printf(ptr @.str, ptr %test)
+  ret i32 %call
+}
+
+; uselistorder directives
+uselistorder ptr @llvm.dbg.declare, { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 18 }
+
+attributes #0 = { nocallback nofree nosync nounwind readnone speculatable willreturn }
+attributes #1 = { "frame-pointer"="all" }
+attributes #2 = { ssp "stack-protector-buffer-size"="5" "frame-pointer"="all" }
+
+!llvm.dbg.cu = !{!0, !2}
+!llvm.module.flags = !{!18, !19, !20, !21, !22, !23, !24}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "frame-diags.c", directory: "")
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, retainedTypes: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "dot.c", directory: "")
+!4 = !{!5, !6, !10, !13}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: null, size: 64)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64)
+!7 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Array", file: !3, line: 3, size: 128, elements: !8)
+!8 = !{!9, !12}
+!9 = !DIDerivedType(tag: DW_TAG_member, name: "data", scope: !7, file: !3, line: 4, baseType: !10, size: 64)
+!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
+!11 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!12 = !DIDerivedType(tag: DW_TAG_member, name: "size", scope: !7, file: !3, line: 5, baseType: !11, size: 32, offset: 64)
+!13 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !14, size: 64)
+!14 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Result", file: !3, line: 8, size: 128, elements: !15)
+!15 = !{!16, !17}
+!16 = !DIDerivedType(tag: DW_TAG_member, name: "data", scope: !14, file: !3, line: 9, baseType: !6, size: 64)
+!17 = !DIDerivedType(tag: DW_TAG_member, name: "sum", scope: !14, file: !3, line: 10, baseType: !11, size: 32, offset: 64)
+!18 = !{i32 7, !"Dwarf Version", i32 5}
+!19 = !{i32 2, !"Debug Info Version", i32 3}
+!20 = !{i32 1, !"wchar_size", i32 4}
+!21 = !{i32 8, !"PIC Level", i32 2}
+!22 = !{i32 7, !"PIE Level", i32 2}
+!23 = !{i32 7, !"uwtable", i32 2}
+!24 = !{i32 7, !"frame-pointer", i32 2}
+!25 = !DILocalVariable(name: "buffer", scope: !26, file: !1, line: 30, type: !32)
+!26 = distinct !DILexicalBlock(scope: !27, file: !1, line: 29, column: 3)
+!27 = distinct !DISubprogram(name: "stackSizeWarning", scope: !1, file: !1, line: 28, type: !28, scopeLine: 28, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !30)
+!28 = !DISubroutineType(types: !29)
+!29 = !{null}
+!30 = !{!25, !31, !36, !37}
+!31 = !DILocalVariable(name: "buffer2", scope: !27, file: !1, line: 33, type: !32)
+!32 = !DICompositeType(tag: DW_TAG_array_type, baseType: !33, size: 640, elements: !34)
+!33 = !DIBasicType(name: "char", size: 8, encoding: DW_ATE_signed_char)
+!34 = !{!35}
+!35 = !DISubrange(count: 80)
+!36 = !DILocalVariable(name: "a", scope: !27, file: !1, line: 34, type: !11)
+!37 = !DILocalVariable(name: "b", scope: !27, file: !1, line: 35, type: !38)
+!38 = !DIBasicType(name: "long", size: 64, encoding: DW_ATE_signed)
+!39 = !DILocation(line: 30, column: 10, scope: !26)
+!40 = !DILocation(line: 33, column: 8, scope: !27)
+!41 = !DILocalVariable(name: "a", arg: 1, scope: !42, file: !3, line: 13, type: !6)
+!42 = distinct !DISubprogram(name: "cleanup_array", scope: !3, file: !3, line: 13, type: !43, scopeLine: 13, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!43 = !DISubroutineType(types: !44)
+!44 = !{null, !6}
+!45 = !{}
+!46 = !DILocation(line: 13, column: 34, scope: !42)
+!47 = !DILocalVariable(name: "res", arg: 1, scope: !48, file: !3, line: 21, type: !13)
+!48 = distinct !DISubprogram(name: "cleanup_result", scope: !3, file: !3, line: 21, type: !49, scopeLine: 21, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!49 = !DISubroutineType(types: !50)
+!50 = !{null, !13}
+!51 = !DILocation(line: 21, column: 36, scope: !48)
+!52 = !DILocalVariable(name: "A", arg: 1, scope: !53, file: !3, line: 32, type: !6)
+!53 = distinct !DISubprogram(name: "do_work", scope: !3, file: !3, line: 32, type: !54, scopeLine: 32, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!54 = !DISubroutineType(types: !55)
+!55 = !{!11, !6, !6, !13}
+!56 = !DILocation(line: 32, column: 27, scope: !53)
+!57 = !DILocalVariable(name: "B", arg: 2, scope: !53, file: !3, line: 32, type: !6)
+!58 = !DILocation(line: 32, column: 44, scope: !53)
+!59 = !DILocalVariable(name: "out", arg: 3, scope: !53, file: !3, line: 32, type: !13)
+!60 = !DILocation(line: 32, column: 62, scope: !53)
+!61 = !DILocalVariable(name: "len", scope: !53, file: !3, line: 37, type: !62)
+!62 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !11)
+!63 = !DILocation(line: 37, column: 13, scope: !53)
+!64 = !DILocalVariable(name: "AB", scope: !53, file: !3, line: 38, type: !6)
+!65 = !DILocation(line: 38, column: 17, scope: !53)
+!66 = !DILocalVariable(name: "sum", scope: !53, file: !3, line: 54, type: !11)
+!67 = !DILocation(line: 54, column: 7, scope: !53)
+!68 = !DILocalVariable(name: "i", scope: !69, file: !3, line: 55, type: !11)
+!69 = distinct !DILexicalBlock(scope: !53, file: !3, line: 55, column: 3)
+!70 = !DILocation(line: 55, column: 12, scope: !69)
+!71 = !DILocalVariable(name: "size", arg: 1, scope: !72, file: !3, line: 62, type: !11)
+!72 = distinct !DISubprogram(name: "gen_array", scope: !3, file: !3, line: 62, type: !73, scopeLine: 62, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!73 = !DISubroutineType(types: !74)
+!74 = !{!6, !11}
+!75 = !DILocation(line: 62, column: 29, scope: !72)
+!76 = !DILocalVariable(name: "res", scope: !72, file: !3, line: 65, type: !6)
+!77 = !DILocation(line: 65, column: 17, scope: !72)
+!78 = !DILocalVariable(name: "i", scope: !79, file: !3, line: 69, type: !11)
+!79 = distinct !DILexicalBlock(scope: !72, file: !3, line: 69, column: 3)
+!80 = !DILocation(line: 69, column: 12, scope: !79)
+!81 = !DILocalVariable(name: "size", scope: !82, file: !3, line: 77, type: !62)
+!82 = distinct !DISubprogram(name: "caller", scope: !3, file: !3, line: 76, type: !83, scopeLine: 76, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !45)
+!83 = !DISubroutineType(types: !84)
+!84 = !{!11}
+!85 = !DILocation(line: 77, column: 13, scope: !82)
+!86 = !DILocalVariable(name: "A", scope: !82, file: !3, line: 78, type: !6)
+!87 = !DILocation(line: 78, column: 17, scope: !82)
+!88 = !DILocalVariable(name: "B", scope: !82, file: !3, line: 79, type: !6)
+!89 = !DILocation(line: 79, column: 17, scope: !82)
+!90 = !DILocalVariable(name: "res", scope: !82, file: !3, line: 80, type: !13)
+!91 = !DILocation(line: 80, column: 18, scope: !82)
+!92 = !DILocalVariable(name: "ret", scope: !82, file: !3, line: 81, type: !11)
+!93 = !DILocation(line: 81, column: 7, scope: !82)
+!94 = !DILocalVariable(name: "err", scope: !82, file: !3, line: 83, type: !11)
+!95 = !DILocation(line: 83, column: 7, scope: !82)