[LLVMdev] Writing a compiler to use LLVM for code generation

[Chris Lattner]

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>