Re: Status of -fstack-usage?

[Olivier Hainque <hainque at adacore dot com>]

Hello Ioannis;

Ioannis E. Venetis wrote:

> > Would __builtin_stack_size (F) retrieve information about F's stack frame
> > only, or would it also recursively account for every other function that
> > F may call ?
> >
> > Implementing the former is probably possible, though I'm not sure
> > exactly how useful it would be. 
 
> I agree that the former is probably not very useful. If a function is
> set to run as a thread and it calls other functions, the stack required
> for those functions should be accounted for. Probably the second option
> is much more useful.

 Sure. It's unfortunately not really an option for complexity reasons.
 
> I had a look here:
> 
> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html
> 
> I think that the best would be __builtin_stack_size(F) to return what is
> described as "dynamic" and "bounded" in the above link.

 I'm afraid there is a misunderstanding here. What -fstack-usage outputs
 for each function is information about the stack used only by the function
 itself. There is no relationship with what the functions it calls do.
 
 The "dynamic" qualifier states whether the function itself allocates
 dynamic amounts of stack, like with an "alloca (n)" and "n" a variable.

 The extra "bounded" qualifier states whether we know a bound for such
 dynamic allocations.
 
> Except from recursive functions, what are the other cases where the
> above size cannot be computed statically?

 Functions often call functions in other compilation units, so this
 almost always is a non-straightforward inter-unit computation issue
 to start with. This is what the accompaning -fcallgraph-info is
 about, together with some tool to merge the per-unit graphs and
 perform computations on the outcome.

 Then, any form of indirect call is a potentially hard source of difficulty
 and there are several variants of those across the languages supported in
 GCC.

 Third, functions we don't compile often come into play.

 And I'm probably forgetting a couple :)