stack usage and scoping

I've just started using LLVM for a project I'm working on, and the
docs seem to encourage the use of alloca, with the expectation that
various optimization passes will optimize away unnecessary stack
pressure. However, I can't seem to figure out how LLVM can properly
re-use stack space, since it doesn't know the extend of a stack
variable. In this simple C example:

extern void foo(char* c);

void bar()
{
   {
     char tmp[1000];
     foo(tmp);
   }

  {
    char tmp[1000];
    foo(tmp);
  }
}

Notice that I have two arrays of 1000 bytes declared, and pass them to
an extern function. If I compile this code with gcc, gcc notices that
the tmp doesn't extend outside of the inner scope that it's defined,
so it can re-use the stack space from the first declaration. If you
look at the assembly generated, gcc only uses something like 1024
bytes of stack space.

However, if I build this code with llvm-gcc, I end up using twice as
much stack space. There doesn't appear to be a way to tell LLVM that
a variable has finite scope. I thought maybe stacksave and
stackrestore would help, but they didn't seem to make any difference.

Note that I'm not planning on using llvm-gcc with my project anyway,
I'm just trying to figure out how LLVM can possibly 'know' about the
extent of a stack variable.

Thanks,
Scott

Hello, Scott

I've just started using LLVM for a project I'm working on, and the
docs seem to encourage the use of alloca, with the expectation that
various optimization passes will optimize away unnecessary stack
pressure. However, I can't seem to figure out how LLVM can properly
re-use stack space, since it doesn't know the extend of a stack
variable.

This is http://llvm.org/bugs/show_bug.cgi?id=3361

Ahh, this states the problem precisely. Does anyone know if there is
active development in this direction? I'd love to be able to use
llvm.lifetime.start() / end().

Scott

Scott Shumaker wrote:

Ahh, this states the problem precisely. Does anyone know if there is
active development in this direction? I'd love to be able to use
llvm.lifetime.start() / end().

Yes, I recently added lifetime.start and friends: http://llvm.org/docs/LangRef.html#int_memorymarkers

However, PR3361 isn't solved. The code generators don't take advantage of that information yet. If you're producing llvm ir, feel free to create them- we'll get around to the optimizations that use them eventually.

Nick