Why extra 4 bytes on stack ???

Hi There ,

Again ,I’m newbie to LLVM and please pardon me …if you guys feel that ,the below question is very basic :slight_smile:

Here i go ,compiled the below sample with clang i.e clang enum.c -S -emit-llvm and there respective file 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” ???

Thanks

Umesh

For some reason even the simplest "int main() { return 0; }" program
allocates those four bytes:

; ModuleID = '/tmp/webcompile/_29079_0.bc'
target datalayout =
"e-p:64:64:64-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-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @main() nounwind uwtable {
  %1 = alloca i32, align 4
  store i32 0, i32* %1
  ret i32 0
}

Hi,

The extra bytes are there because you didn't compile with any optimisation.
Clang defaults to -O0, so give it -O1 or -O2 to remove those dead stack
slots.

Cheers,

James

Hi Alexander,

For some reason even the simplest "int main() { return 0; }" program
allocates those four bytes:

; ModuleID = '/tmp/webcompile/_29079_0.bc'
target datalayout =
"e-p:64:64:64-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-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @main() nounwind uwtable {
   %1 = alloca i32, align 4
   store i32 0, i32* %1
   ret i32 0
}

this is a clang oddity (dragonegg doesn't do this). Presumably the clang
developers found it convenient to do this. It doesn't matter since the
optimizers will zap the useless alloca.

Ciao, Duncan.

Hi There ,

I’m new to Clang and please pardon me …if you guys feel that ,the below question is very basic :slight_smile:

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 ??

Thanks
~Umesh

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.

– Matthieu

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.

Hi John and Matthieu,

Thank you very much for the details :slight_smile:

~Umesh