buildbot failure in LLVM on sanitizer-x86_64-linux (-Wframe-larger-than)

Hi Alp,

This warning should be fixed by r210301. However, consider investigating why the frame size appears to be that large. I believe we build this code with GCC as well and have seen no complaints
from its implementation of -Wframe-larger-than.

CC'ing in llvmdev. Like Chandler said it could just be due to lack of stack sharing compared to GCC. There's a lot going on between the time when we generate IR from AST to the time this final machine pass is run. GCC might just be optimizing differently.

On the other hand it could indeed be that LLVM's DiagnosticInfoStackSize is giving us a different value or computation than GCC's -Wframe-larger-than. It's worth double checking that we're using a similar function frame size computation here.

Let's not write off either possibility given that the LLVM value wasn't originally intended for GCC compatibility -- we just spun it that way in the frontend :slight_smile:

Quentin, thoughts?

Alp.

Hi,

Hi Alp,

This warning should be fixed by r210301. However, consider investigating why the frame size appears to be that large. I believe we build this code with GCC as well and have seen no complaints
from its implementation of -Wframe-larger-than.

CC’ing in llvmdev. Like Chandler said it could just be due to lack of stack sharing compared to GCC. There’s a lot going on between the time when we generate IR from AST to the time this final machine pass is run. GCC might just be optimizing differently.

On the other hand it could indeed be that LLVM’s DiagnosticInfoStackSize is giving us a different value or computation than GCC’s -Wframe-larger-than. It’s worth double checking that we’re using a similar function frame size computation here.

I do not know what exactly GCC is giving for -Wframe-larger-than, but based on the description in the documentation I would say it is likely we are not returning the same thing in LLVM.
Indeed, GCC documentation says:

`-Wframe-larger-than=`
Warn if the size of a function frame is larger than bytes. The computation done to determine the stack frame size is approximate and not conservative. The actual requirements may be somewhat greater than 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.

Whereas in our case, we give the actual size in bytes we reserve on the stack to store the statically known object (locals and/or spills).

In that case, if the reported size is completely off the actual generated code, it is worth filing a PR. Otherwise, we may need to refine the documentation the semantic of the warning for LLVM.

Thanks,
-Quentin

Hi,

Hi Alp,

This warning should be fixed by r210301. However, consider investigating why the frame size appears to be that large. I believe we build this code with GCC as well and have seen no complaints
from its implementation of -Wframe-larger-than.

CC'ing in llvmdev. Like Chandler said it could just be due to lack of stack sharing compared to GCC. There's a lot going on between the time when we generate IR from AST to the time this final machine pass is run. GCC might just be optimizing differently.

On the other hand it could indeed be that LLVM's DiagnosticInfoStackSize is giving us a different value or computation than GCC's -Wframe-larger-than. It's worth double checking that we're using a similar function frame size computation here.

I do not know what exactly GCC is giving for -Wframe-larger-than, but based on the description in the documentation I would say it is likely we are not returning the same thing in LLVM.
Indeed, GCC documentation says:
>-Wframe-larger-than=|len
    Warn if the size of a function frame is larger than len bytes. The
    computation done to determine the stack frame size is approximate
    and not conservative. The actual requirements may be somewhat
    greater than len 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.

Whereas in our case, we give the actual size in bytes we reserve on the stack to store the statically known object (locals and/or spills).

In that case, if the reported size is completely off the actual generated code, it is worth filing a PR. Otherwise, we may need to refine the documentation the semantic of the warning for LLVM.

That explains it, nice investigatory work Quentin :slight_smile:

I guess the behaviour we have is a safe superset of GCC's warning for now though we might want to document it at some point.

It actually sounds like we're well on the way to covering GCC's -Wstack-usage=len which includes "space allocated via alloca, variable-length arrays, or related constructs". But that also identifies whether there are unbounded/dynamic allocas which we don't have. Would it be possible to feed that information through to the frontend as well?

Alp.