[LLVMdev] Stack usage analysis using LLVM

John Criswell criswell at illinois.edu
Thu Sep 5 12:04:28 PDT 2013


On 9/3/13 1:27 PM, Snehasish Kumar wrote:
> Hi
>
> I was wondering if someone knows about any effort within the LLVM 
> community to perform stack usage analysis per function similar to 
> GCC's "-fstack-usage 
> <http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html>" 
> option?

I am not familiar with the -fstack-usage option in GCC, but as far as I 
know, LLVM does not have a FunctionPass or MachineFunctionPass which 
performs the calculations described below.  You could, of course, 
quickly test this by running the clang -fstack-usage and see what 
happens.  LLVM and the DragonEgg plugin for GCC is more likely to 
support the feature.

That said, writing such as pass would be very easy to do.  If you're 
only concerned about the size of stack-allocated objects, you can write 
an LLVM pass that looks for alloca instructions, determine that they are 
not in loops, and then sums up the sizes of the allocatoed memory using 
the DataLayout pass.

If you want something that includes stack-spill slots and the like, then 
you'd need to write a MachineFunction Pass and examine the generated 
machine instructions.  Alternatively, there might be a way in a 
MachineFunctionPass to get a pointer to a MachineFrame object and to 
query its size.

-- John T.

>
> In short, with fstack-usage, gcc prints out the maximum stack usage 
> per function (in bytes) which it can determine as a) static (no calls 
> to alloca in source) b) bounded (calls to alloca with constants) c) 
> unbounded (calls to alloca with variables). A more detailed 
> description can be found in this pdf 
> <http://ols.fedoraproject.org/GCC/Reprints-2005/hainque-Reprint.pdf>.
>
>
> Thanks,
> Snehasish Kumar
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130905/05e008de/attachment.html>


More information about the llvm-dev mailing list