llvm dev - Jul 2013 - [LLVMdev] intended use/structure of AllocA/local variables

I'm trying to determine what is the best approach to using AllocA.
Currently I just allocate all my variables at the beginning of the
function but wondering if they should rather be done closer to the scope
they are used. This would also require a way to do a free on the
allocated structure, but there doesn't appear to be such a function.

Is it the intent that all stack variables are alloc'd at the beginning
of the function? I guess this has the advantage that LLVM then knows the
full size of the function's stack at entry and can just use fixed
offsets for all variables. It has the disadvantage that all potentially
used stack variables are always allocated, which uses more stack memory
than is actually required.

What's the intended practice with AllocA?

Can the optimizer determine when the use of two AllocA spaces is
exclusive and share the stack space?

-- 
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130702/1f17ff39/attachment.sig>

Hi,

On 02/07/13 05:14, edA-qa mort-ora-y wrote:
> I'm trying to determine what is the best approach to using AllocA.
> Currently I just allocate all my variables at the beginning of the
> function but wondering if they should rather be done closer to the scope
> they are used. This would also require a way to do a free on the
> allocated structure, but there doesn't appear to be such a function.
just allocate them at the start and use lifetime intrinsics to tell LLVM
when they are actually in use.
>
> Is it the intent that all stack variables are alloc'd at the beginning
> of the function? I guess this has the advantage that LLVM then knows the
> full size of the function's stack at entry and can just use fixed
> offsets for all variables. It has the disadvantage that all potentially
> used stack variables are always allocated, which uses more stack memory
> than is actually required.
>
> What's the intended practice with AllocA?
>
> Can the optimizer determine when the use of two AllocA spaces is
> exclusive and share the stack space?
The code generators will reuse stack space if it can.  You can help it out
using the lifetime intrinsics mentioned above.

Ciao, Duncan.