[cfe-dev] Why extra 4 bytes on stack ???

[John McCall]

On Feb 2, 2012, at 10:59 AM, Matthieu Monrocq wrote:
> Le 2 février 2012 12:48, Umesh Kalappa <umesh.kalappa0 at gmail.com> a écrit :
> Hi There ,
> 
> I'm new  to Clang   and please pardon me ..if you guys  feel that ,the below question is very basic :) 
> 
> Here i go ,compiled the below sample with clang i.e clang enum.c -S -emit-llvm and  respective files are 
> 
> $ cat enum.c
> int main()
> {
>  enum type{one=1,two,three} s;
>  s = one;
>  return s;
> }
> 
> $ cat enum.s
> ; ModuleID = 'enum.c'
> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32"
> target triple = "i386-pc-cygwin"
> 
> define i32 @main() nounwind {
>   %1 = alloca i32, align 4
>   %s = alloca i32, align 4
>   store i32 0, i32* %1
>   store i32 1, i32* %s, align 4
>   %2 = load i32* %s, align 4
>   ret i32 %2
> }
> 
> Question : Why there is  extra 4 bytes on stack i.e  "%1 = alloca i32, align 4"  ???
> 
> Note : Please note that the  LLVM transformation will free away those extra space ,But still like to know why Clang at first shot introduces those extra spaces ?? 
> 
> It looks to me like %1 is allocated just in case we would need it for a "ret i32 %1" instruction at the end of main (since it's not mandatory for the user to define it). The "store i32 0, i32* %1" seems to agree with this understanding, as 0 is the default return value.

Yes.  We allocate an implicit local variable to hold the return value;  return statements then just initialize the return slot and jump to the epilogue, where the slot is loaded and returned.  We don't use a phi because the control flow for getting to the epilogue is not necessarily as simple as a simple branch, due to cleanups in local scopes (like C++ destructors).

Implicit return values like main's are handled with an implicit store in the prologue.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120202/d0677526/attachment.html>