llvm dev - Aug 2017 - [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,

Sean Eveson
SN Systems - Sony Interactive Entertainment
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170831/71b43c08/attachment.html>

On 08/31/2017 09:09 AM, Sean Eveson via llvm-dev 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.
>
I'd certainly be interested in this, although I'd hope it were not 
specific to x86.

  -Hal
> 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
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170831/1604f9a5/attachment.html>

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
> On Aug 31, 2017, at 7:09 AM, 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/20170831/af9ea632/attachment-0001.html>

> On Aug 31, 2017, at 7:09 AM, 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.
> 
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
>  
> 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/20170831/99a2a8d9/attachment.html>

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.

On Thu, Aug 31, 2017 at 7:09 AM, 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/20170831/55daac66/attachment.html>

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
>

I'm sorry if this mail is unhelpful, feel free to ignore it :)
> 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.
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 at 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).

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>