Hi Duncan, Appreciate you response here and yeah any optimization switch for clang will make this extra bytes go away ...Was very curious to know why these extra bytes for and can you please elaborate more on "for storing the return value in more complicated cases" ...That helps me understand the LLVM internals :) Thanks ~Umesh On Thu, Feb 2, 2012 at 2:19 PM, Duncan Sands <baldrick at free.fr> wrote:> Hi Umesh, > > > Again ,I'm newbie to LLVM 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 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"* ??? > > I think this would normally be used for storing the return value in more > complicated cases. If you compile with optimization it will go away. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120202/c8edf052/attachment.html>
Hi Umesh,
The compiler generates an alloca (stack space) for every local variable defined
in a function. Along with local variables this also includes space to store the
function parameters and also the variable that holds the return value.
For example:
Int x(int a, int b) {
Return a + b;
}
Would compile to something like this:
Define i32 @x(i32 %a, i32 %b) {
%ret.addr = alloca i32
%a.addr = alloca i32
%b.addr = alloca i32
Store i32 %a, i32 *%a.addr
Store i32 %b, i32 *%b.addr
%1 = load i32* %a.addr
%2 = load i32* %b.addr
%3 = add nsw i32 %1, %2
Store i32 %3, i32* %ret.addr
%4 = load i32* %ret.addr
Ret %4
}
So firstly Clang would create variables on the stack to hold the parameters and
the return value, then store the parameters there (function prologue).
Then, to perform the add, it would load the arguments from their local variable
storage (in this case %a.addr and %b.addr), perform the add and write the result
back to its local variable storage (%ret.addr)
Finally to return it will load the return value variable and return it.
Does this make things clearer?
Cheers,
James
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Umesh Kalappa
Sent: 02 February 2012 09:04
To: Duncan Sands
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] (no subject)
Hi Duncan,
Appreciate you response here and yeah any optimization switch for clang will
make this extra bytes go away ...Was very curious to know why these extra bytes
for and can you please elaborate more on "for storing the return value in
more complicated cases" ...That helps me understand the LLVM internals :)
Thanks
~Umesh
On Thu, Feb 2, 2012 at 2:19 PM, Duncan Sands <baldrick at
free.fr<mailto:baldrick at free.fr>> wrote:
Hi Umesh,
> Again ,I'm newbie to LLVM 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 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"* ???
I think this would normally be used for storing the return value in more
complicated cases. If you compile with optimization it will go away.
Ciao, Duncan.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120202/d5dcd4cb/attachment.html>
Hi James,
Thank you very much for the explanation .
FYI .LLVM Dead store elimination (DSE) transformation eliminates those
extra bytes. i.e
$ opt -f -S -dse enum.s
; ModuleID = 'enum.s'
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 {
%s = alloca i32, align 4
store i32 1, i32* %s, align 4
%1 = load i32* %s, align 4
ret i32 %1
}
Duncan, Debugging the Clang source code here for the reason "why these
extra bytes",But still you have anything in your kit,Please let me know
:).
Thanks
~Umesh
On Thu, Feb 2, 2012 at 2:54 PM, James Molloy <James.Molloy at arm.com>
wrote:
> Hi Umesh,****
>
> ** **
>
> The compiler generates an alloca (stack space) for every local variable
> defined in a function. Along with local variables this also includes space
> to store the function parameters and also the variable that holds the
> return value.****
>
> ** **
>
> For example:****
>
> ** **
>
> Int x(int a, int b) {****
>
> Return a + b;****
>
> }****
>
> ** **
>
> Would compile to something like this:****
>
> ** **
>
> Define i32 @x(i32 %a, i32 %b) {****
>
> %ret.addr = alloca i32****
>
> %a.addr = alloca i32****
>
> %b.addr = alloca i32****
>
> ** **
>
> Store i32 %a, i32 *%a.addr****
>
> Store i32 %b, i32 *%b.addr****
>
> ** **
>
> %1 = load i32* %a.addr****
>
> %2 = load i32* %b.addr****
>
> ** **
>
> %3 = add nsw i32 %1, %2****
>
> ** **
>
> Store i32 %3, i32* %ret.addr****
>
> ** **
>
> %4 = load i32* %ret.addr****
>
> Ret %4****
>
> }****
>
> ** **
>
> So firstly Clang would create variables on the stack to hold the
> parameters and the return value, then store the parameters there (function
> prologue).****
>
> ** **
>
> Then, to perform the add, it would load the arguments from their local
> variable storage (in this case %a.addr and %b.addr), perform the add and
> write the result back to its local variable storage (%ret.addr)****
>
> ** **
>
> Finally to return it will load the return value variable and return it.***
> *
>
> ** **
>
> Does this make things clearer?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> James****
>
> ** **
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *Umesh Kalappa
> *Sent:* 02 February 2012 09:04
> *To:* Duncan Sands
> *Cc:* llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] (no subject)****
>
> ** **
>
> Hi Duncan,****
>
> Appreciate you response here and yeah any optimization switch for clang
> will make this extra bytes go away ...Was very curious to know why these
> extra bytes for and can you please elaborate more on "for storing
the
> return value in****
>
> more complicated cases" ...That helps me understand the LLVM internals
:)
> ****
>
> ** **
>
> Thanks ****
>
> ~Umesh ****
>
> ** **
>
> On Thu, Feb 2, 2012 at 2:19 PM, Duncan Sands <baldrick at free.fr>
wrote:****
>
> Hi Umesh,****
>
>
> > Again ,I'm newbie to LLVM 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 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"* ???
>
> I think this would normally be used for storing the return value in more
> complicated cases. If you compile with optimization it will go away.
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev****
>
> ** **
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120202/c0a610db/attachment.html>