[RFC] Function stack size section.

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,

I’d certainly be interested in this, although I’d hope it were not specific to x86. -Hal

This sounds nice! I’d prefer a more general cross-platform patch personally. I can imagine that this would be useful to know for, say, ARM/AArch64 as well.

  • Jessica

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.

Have you considered using optimization remarks for this rather than rolling your own infrastructure. Francis (cc’ed) did something like this in https://reviews.llvm.org/D35645.

Adam

Hello Sean,
I can’t really comment on the implementation details ( optimization remarks vs object section); But we would certainly be interested in a generic way to extract stack size information.

On the subject of stack size, have you done any gcc vs llvm comparison ? Last time we look at it, LLVM seems to generate larger stack size than gcc (especially at higher inline thresholds) . I am curious if other people have noticed the same thing.

Compiler Engineering @ Facebook,inc.

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

I'm sorry if this mail is unhelpful, feel free to ignore it :slight_smile:

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.

GCC has three seemingly-related diagnostics:
-Wlarger-than=len
   Warn whenever an object of larger than len bytes is defined.
-Wframe-larger-than=len
   Warn if the size of a function frame is larger than len bytes.
-Wstack-usage=len
   Warn if the stack usage of a function might be larger than len bytes.

I *believe*, clang only implements the
-Wframe-larger-than=len
   Warn if the size of a function frame is larger than len bytes.

So while possibly not directly related to the subject, it may still be
relevant...

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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Roman.

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