[llvm-dev] [RFC] Function stack size section.

[Sean Eveson via llvm-dev]

Hi All,

It's good to hear other people are interested.

> Have you considered using optimization remarks for this rather than
rolling your own infrastructure.

This could work for our local testing with significant infrastructure
changes, but we have some other use cases where using the remarks wouldn't
work or wouldn't be convenient.

- Getting stack sizes from binaries that we didn't build
- Providing stack size data to users when they inspect their own binaries

> Can you let us know what the change above does that reading the stack
> size from the .debug_frame or .eh_frame doesn't?

We won't have the .debug_frame on release builds. The .eh_frame does not
always have enough information to calculate the stack sizes (I understand
that this might not be the case for ARM).

Thanks,

Sean Eveson
SN Systems - Sony Interactive Entertainment

On Fri, Sep 1, 2017 at 9:48 AM, Peter Smith <peter.smith at linaro.org> wrote:

> Hello Sean,
>
> This is potentially interesting to Arm and other targets that end up
> in embedded systems. Of particular use for this information is
> estimating the maximum stack usage for the program.
>
> In Arm's proprietary toolchain we use the .debug_frame information to
> calculate the per-function stack-size. This is a bit more work than
> just reading off the value from a table but it doesn't require any
> custom compiler work or special ELF sections, and does work with
> assembler assuming that the author has put in the necessary
> directives. It has the downside of always requiring .debug_frame (or
> .eh_frame) sections for release builds.
>
> Can you let us know what the change above does that reading the stack
> size from the .debug_frame or .eh_frame doesn't?
>
> Peter
>
> On 31 August 2017 at 15:09, Sean Eveson via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hi All,
> >
> >
> >
> > We have a local change in the X86AsmPrinter that outputs a section
> > containing metadata on function stack sizes. We use this to measure
> changes
> > to stack size between versions of the compiler and it also allows our
> > licensees to do the same for their code.
> >
> >
> >
> > The section simply contains pairs of function symbol references (8 byte)
> and
> > stack sizes (unsigned LEB128).
> >
> >
> >
> > We would like to upstream this change as a PS4 only modification, or as a
> > more general cross platform one.
> >
> >
> >
> > Would people be interested in (or happy with) such a patch, target
> specific
> > or otherwise?
> >
> >
> >
> > Thanks,
> >
> >
> > Sean Eveson
> > SN Systems - Sony Interactive Entertainment
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170901/05962491/attachment-0001.html>