[llvm-dev] [RFC] Function stack size section. (original) (raw)

Sean Eveson via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 1 10:08:08 PDT 2017

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.

Can you let us know what the change above does that reading the stack size from the .debugframe or .ehframe 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 .debugframe 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 .debugframe (or .ehframe) sections for release builds. Can you let us know what the change above does that reading the stack size from the .debugframe or .ehframe 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>

More information about the llvm-dev mailing list