Roman Lebedev via llvm-dev
2021-May-06 07:35 UTC
[llvm-dev] Implementing "-Wstack-usage=" warning flag
Thank you for looking into it! I think while these diagnostics may be niche, they may be quite important, especially given that clang static analyzer does not implement a proper check for maximal stack usage of a program. How will this cooperate with parallel implementation in https://reviews.llvm.org/D100509 ? I think current clang's -Wframe-larger-than= does not match either one of the GCC options: https://godbolt.org/z/ehTaEMjW5 I guess it only counts the allocas within the function? There, it is visible that the stack usage is the cumulative size of all the allocas within the function's body, while frame-size also includes arguments into that computation. Which, i think is consistent with https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html * -Wstack-usage=byte-size Warn if the stack usage of a function might exceed byte-size. The computation done to determine the stack usage is conservative. Any space allocated via alloca, variable-length arrays, or related constructs is included by the compiler when determining whether or not to issue a warning. * -Wframe-larger-than=byte-size Warn if the size of a function frame exceeds byte-size. The computation done to determine the stack frame size is approximate and not conservative. The actual requirements may be somewhat greater than byte-size even if you do not get a warning. In addition, any space allocated via alloca, variable-length arrays, or related constructs is not included by the compiler when determining whether or not to issue a warning -Wframe-larger-than=‘PTRDIFF_MAX’ is enabled by default. Warnings controlled by the option can be disabled either by specifying byte-size of ‘SIZE_MAX’ or more or by -Wno-frame-larger-than. Roman On Thu, May 6, 2021 at 4:55 AM David Blaikie <dblaikie at gmail.com> wrote:> > +Roman Lebedev > > Roman - what was your particular motivation for filing the bug? Is > there a use case that -Wframe-larger-than doesn't cover? Would > -Wstack-usage as an alias for -Wframe-larger-than be adequate for your > use case (if directly using the existing flag is not sufficient for > some reason)? > > On Wed, May 5, 2021 at 6:32 PM Ryan Santhirarajan via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello everyone, > > > > > > > > I am trying to address the following bug: > > https://bugs.llvm.org/show_bug.cgi?id=44418 > > > > Which asks for the implementation of the missing “-Wstack-usage=” which will report, on a per-function basis, if the stack usage exceeds the user input. > > > > > > > > My first approach at implementing “-Wstack-usage” is the following: > > > > https://reviews.llvm.org/D101965 > > > > This is virtually identical to the output of “-Wframe-larger-than” on clang. However when observing the behaviour of GCC I noticed that GCC outputs different values for “-Wstack-usage” and “-Wframe-larger-than”. > > > > > > > > This led me to my second approach which changes the way clang reports “-Wframe-larger-than”. This can be found here: > > https://reviews.llvm.org/D101964 > > > > With this second approach, “-Wframe-larger-than” now reports the stack size minus any space allocated on the stack for the parameters of called functions. This more closely resembles GCC’s behaviour. > > > > > > > > I am unsure which implementation is preferred/correct and I am wondering if anyone can comment or provide some information on what a better approach would be, and what exactly the two flags should be reporting. > > > > > > > > Thanks, > > > > Ryan Santhirarajan > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Ryan Santhirarajan via llvm-dev
2021-May-18 14:50 UTC
[llvm-dev] Implementing "-Wstack-usage=" warning flag
Hi Roman, It seems that there isn't really a consensus on what the most "correct" approach is as there already exists a discrepancy between LLVM and GCC behaviour. I suggest that we proceeed with the less invasive of the two approaches, https://reviews.llvm.org/D101965, and if we decide to update "-Wframe-larger-than=" and "-Wstack-usage=" that can be addressed later. As it stands now the two flags will report similar information. My change cooperates well with the change you pointed out, https://reviews.llvm.org/D100509 , it actually reports very similar results albeit in different forms. Regards, Ryan -----Original Message----- From: Roman Lebedev <lebedev.ri at gmail.com> Sent: Thursday, May 6, 2021 12:35 AM To: David Blaikie <dblaikie at gmail.com> Cc: Ryan Santhirarajan <rsanthir at quicinc.com>; llvm-dev at lists.llvm.org; Chris Jenneisch <chrisj at quicinc.com>; Pengxuan Zheng <pzheng at quicinc.com> Subject: [EXT] Re: [llvm-dev] Implementing "-Wstack-usage=" warning flag Thank you for looking into it! I think while these diagnostics may be niche, they may be quite important, especially given that clang static analyzer does not implement a proper check for maximal stack usage of a program. How will this cooperate with parallel implementation in https://reviews.llvm.org/D100509 ? I think current clang's -Wframe-larger-than= does not match either one of the GCC options: https://godbolt.org/z/ehTaEMjW5 I guess it only counts the allocas within the function? There, it is visible that the stack usage is the cumulative size of all the allocas within the function's body, while frame-size also includes arguments into that computation. Which, i think is consistent with https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html * -Wstack-usage=byte-size Warn if the stack usage of a function might exceed byte-size. The computation done to determine the stack usage is conservative. Any space allocated via alloca, variable-length arrays, or related constructs is included by the compiler when determining whether or not to issue a warning. * -Wframe-larger-than=byte-size Warn if the size of a function frame exceeds byte-size. The computation done to determine the stack frame size is approximate and not conservative. The actual requirements may be somewhat greater than byte-size even if you do not get a warning. In addition, any space allocated via alloca, variable-length arrays, or related constructs is not included by the compiler when determining whether or not to issue a warning -Wframe-larger-than=‘PTRDIFF_MAX’ is enabled by default. Warnings controlled by the option can be disabled either by specifying byte-size of ‘SIZE_MAX’ or more or by -Wno-frame-larger-than. Roman On Thu, May 6, 2021 at 4:55 AM David Blaikie <dblaikie at gmail.com> wrote:> > +Roman Lebedev > > Roman - what was your particular motivation for filing the bug? Is > there a use case that -Wframe-larger-than doesn't cover? Would > -Wstack-usage as an alias for -Wframe-larger-than be adequate for your > use case (if directly using the existing flag is not sufficient for > some reason)? > > On Wed, May 5, 2021 at 6:32 PM Ryan Santhirarajan via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello everyone, > > > > > > > > I am trying to address the following bug: > > https://bugs.llvm.org/show_bug.cgi?id=44418 > > > > Which asks for the implementation of the missing “-Wstack-usage=” which will report, on a per-function basis, if the stack usage exceeds the user input. > > > > > > > > My first approach at implementing “-Wstack-usage” is the following: > > > > https://reviews.llvm.org/D101965 > > > > This is virtually identical to the output of “-Wframe-larger-than” on clang. However when observing the behaviour of GCC I noticed that GCC outputs different values for “-Wstack-usage” and “-Wframe-larger-than”. > > > > > > > > This led me to my second approach which changes the way clang reports “-Wframe-larger-than”. This can be found here: > > https://reviews.llvm.org/D101964 > > > > With this second approach, “-Wframe-larger-than” now reports the stack size minus any space allocated on the stack for the parameters of called functions. This more closely resembles GCC’s behaviour. > > > > > > > > I am unsure which implementation is preferred/correct and I am wondering if anyone can comment or provide some information on what a better approach would be, and what exactly the two flags should be reporting. > > > > > > > > Thanks, > > > > Ryan Santhirarajan > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev