llvm dev - Mar 2011 - [LLVMdev] Writing a compiler to use LLVM for code generation

On Feb 14, 2011, at 9:15 AM, Jim Darby wrote:
> Hi Chris,
> Thanks for the pointer to the LLVM tutorial, it's helped immensely.
> I've been playing around a bit to see how clang generates the IR and it
now all makes a lot more sense. However, there's one issue that's
causing me a little concern. It all centres around allocating local variables
using the alloca operation with block structured code.
> Using C as an example language, consider the following example program.
> 	void
> 	bar ()
> 	{
>   		extern void called (char *);
>   		{
>     			char x1 [10000];
>     			called (x1);
>   		}
>   		{
>     			char x2 [15000];
>     			arse (x2);
>   		}
> 	}
> Now in C it is possible to overlap the storage for x1 and x2. In fact the
stack frame can be considered something like union { char x1[10000]; char
x2[15000]; }. In the general case the blocks of the same lexical level inside a
function can all be considered as forming part of a union. However, I notice the
clang generates the space for both x1 and x2 at the same time meaning the above
function allocates 25000 bytes on the stack when it only need create 15000.
> If you put the same code through gcc you'll find it only allocates just
over 15000 bytes of local storing (the 15000 plus a little overhead).
> This has no effect on performance but does have an effect on the amount of
stack space a program uses. Now I know that we shouldn't be allocating vast
amounts on the stack but the above program is just an example to prove the
point.
> Any thoughts on this one? One potential method is to actually form a union
to handle the stack frame and use that explicitly. This has the rather novel
effect that all functions would only have a single alloca to create all the
local variables.
> Many thanks for your help,
> Jim.
Hi Jim,

It's best to email llvmdev with general questions, as I get swamped and
backlogged frequently.  We don't have a good answer at present to the
problem above, but I have some thoughts on the matter here:
http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt

We do currently have a hack in the inliner to reuse stack array memory that are
inlined from different callees into a common caller.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/e5846085/attachment.html>