[LLVMdev] freeing alloca'd variables before function exits

Eric Christopher echristo at gmail.com
Sun Nov 3 15:24:07 PST 2013


We treat allocas in the entry block as normal stack space and allocas
outside the entry block as similar to C alloca calls. You likely want all
of your local variables allocated in the entry block. It should help.
On Nov 3, 2013 12:04 PM, "Ali Javadi" <aj14889 at yahoo.com> wrote:

> Hi,
>
> In my llvm code I want to create some function calls. The function
> prototype is as follows:
>
> int memoize ( char *function_name,
>                 int *int_params, unsigned num_ints,
>                double *double_params, unsigned num_doubles)
>
> In order to create these calls I do the following for example:
>
>   %88 = *alloca* [7 x i8]
>   store volatile [7 x i8] c"ORACLE\00", [7 x i8]* %88
>   %89 = getelementptr [7 x i8]* %88, i32 0, i32 0
>
>   %90 = *alloca* [1 x i32]
>   %91 = getelementptr inbounds [1 x i32]* %90, i32 0, i32 0
>   store volatile i32 3, i32* %91
>   %92 = getelementptr inbounds [1 x i32]* %90, i32 0, i32 0
>
>   %93 = *alloca* [0 x double]
>   %94 = getelementptr inbounds [0 x double]* %93, i32 0, i32 0
>
>   %95 = call i32 @memoize(i8* %89, i32* %92, i32 1, double* %94, i32 0)
>
> This works, but I need to create *many* such function calls in one
> "parent" function, and eventually all the "*alloca*" instructions add up
> to overflowing the stack. So I have two questions:
>
> a) Is it possible to create the arrays for my function call args without
> using the alloca instruction (maybe use heap)?
> b) If not, can I release those alloca'd spaces during the function
> execution and not after it returns?
>
> Thanks,
> Ali
>
> _______________________________________________
> 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/20131103/b828a394/attachment.html>


More information about the llvm-dev mailing list