On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote:> On Thu, 17 Apr 2008, guan mailist wrote: > > Does anyone have good ideas to dynamically measure the stack size of a > > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do so? > > Depending on how much precision you need, you could use the > llvm.frameaddress intrinsic.Chris: This prompts me to a related question. For procedures that do not call alloca() at run time, is there a way to learn the stack frame size in bytes for each procedure at static compile time? shap
On Apr 17, 2008, at 13:00, Jonathan S. Shapiro wrote:> On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > >> On Thu, 17 Apr 2008, guan mailist wrote: >> >>> Does anyone have good ideas to dynamically measure the stack size >>> of a >>> program by using LLVM. I am trying to add some new intrinsic >>> functions after each "alloca" in bitcode. Is it a good way to do >>> it? Any existing tools can help me to do so? >> >> Depending on how much precision you need, you could use the >> llvm.frameaddress intrinsic. > > This prompts me to a related question. For procedures that do not > call alloca() at run time, is there a way to learn the stack frame > size in bytes for each procedure at static compile time?The GC infrastructure exposes this information in a framework suitable for emitting metadata tables from a compiler plugin, if your interest lies in that direction. — Gordon
On Thu, 2008-04-17 at 13:39 -0400, Gordon Henriksen wrote:> On Apr 17, 2008, at 13:00, Jonathan S. Shapiro wrote: > > This prompts me to a related question. For procedures that do not > > call alloca() at run time, is there a way to learn the stack frame > > size in bytes for each procedure at static compile time? > > > The GC infrastructure exposes this information in a framework suitable > for emitting metadata tables from a compiler plugin, if your interest > lies in that direction.That too, but my immediate interest was computing an upper bound on stack size for the Coyotos kernel. shap
On Thu, 17 Apr 2008, Jonathan S. Shapiro wrote:>> Depending on how much precision you need, you could use the >> llvm.frameaddress intrinsic. > > Chris: > > This prompts me to a related question. For procedures that do not call > alloca() at run time, is there a way to learn the stack frame size in > bytes for each procedure at static compile time?I think it is dumped if you pass -print-machineinstrs to llc. -Chris -- http://nondot.org/sabre/ http://llvm.org/
> This prompts me to a related question. For procedures that do not call > alloca() at run time, is there a way to learn the stack frame size in > bytes for each procedure at static compile time?The linux kernel uses the attached script to check the stack usage of functions. Ciao, Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: checkstack.pl Type: application/x-perl Size: 4349 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080417/7a6d8f61/attachment.bin>