<div dir="auto">Hi, Kai<div><br></div><div>thanks. but I mean the alloca in llvm IR, not alloca in C. </div><div><br></div><div><br></div><div>Best Regards,</div><div>Jerry<br><br></div></div><div style="line-height:1.5"><br><br>-------- 原始邮件 --------<br>发件人： Kai Luo <gluokai@gmail.com><br>日期： 2020年12月23日周三 晚上7:26<br>收件人： 林政宗 <jackie_linzz@126.com><br>抄送： Tim Northover <t.p.northover@gmail.com>, llvm-dev@lists.llvm.org<br>主    题： Re: [llvm-dev] alloca behavior in llvm IR<br><blockquote>Hi 林政宗,<br>  As Tim has mentioned `alloca` which is included in `<alloca.h>`, I<br>think you can write some demos and observe what the behavior is. For<br>example,<br>```<br>#include <alloca.h><br><br>void foo(void *);<br>bool bar(void);<br>void spam() {<br> if (bar()) {<br>   auto *p = alloca(1024);<br>   foo(p);<br> }<br>}<br>```<br>which gives LLVM IR<br>```<br>; Function Attrs: uwtable mustprogress<br>define dso_local void @_Z4spamv() local_unnamed_addr #0 {<br>entry:<br> %call = tail call zeroext i1 @_Z3barv()<br> br i1 %call, label %if.then, label %if.end<br><br>if.then:                                          ; preds = %entry<br> %0 = alloca [1024 x i8], align 16<br> %.sub = getelementptr inbounds [1024 x i8], [1024 x i8]* %0, i64 0, i64 0<br> call void @_Z3fooPv(i8* nonnull %.sub)<br> br label %if.end<br><br>if.end:                                           ; preds = %if.then, %entry<br> ret void<br>}<br>```<br>Best regards,<br>Kai<br><br>On Wed, Dec 23, 2020 at 7:04 PM 林政宗 via llvm-dev<br><llvm-dev@lists.llvm.org> wrote:<br>><br>> Hi, Tim.<br>><br>> I am also not quite clear about the convention of alloca.<br>> when the size of a variable is known at compile-time, is it always that clang will put the alloca for the variable at the start of entry block?<br>> when will clang put alloca at other block? And when will clang put alloca at entry block?<br>> when clang put alloca at other block, does it mean that the size of the variable of alloca is not known at compile-time?<br>> Thanks!<br>><br>> Best Regards,<br>> Jerry<br>><br>><br>><br>> At 2020-12-17 15:43:58, "Tim Northover" <t.p.northover@gmail.com> wrote:<br>> >On Wed, 16 Dec 2020 at 13:52, 林政宗 <jackie_linzz@126.com> wrote:<br>> >> When there are dynamic allocas, is it always that the compiler will insert @llvm.stacksave() and @llvm.stackrestore()?<br>> ><br>> >Clang always emits them for variable length arrays as far as I know<br>> >(e.g. "int arr[n]"), but C's actual "alloca" function<br>> >(https://www.man7.org/linux/man-pages/man3/alloca.3.html) makes the<br>> >memory available until the function returns so Clang can't use<br>> >stackrestore anywhere there.<br>> ><br>> >> When there is a need to insert @llvm.stacksave() and @llvm.stackrestore(), how does the compiler decide where it should insert them?<br>> ><br>> >The stacksave should go just before the alloca you want to reclaim<br>> >later, which is usually pretty easy to do.<br>> ><br>> >The stackrestore ideally goes just after the last instruction that<br>> >uses the memory involved. That's difficult to determine though (and<br>> >impossible to implement if it happens in another function). So in<br>> >practice source languages have scoping rules that say when a variable<br>> >is *allowed* to be accessed, and compilers put the stackrestore at the<br>> >end of the scope.<br>> ><br>> >In C and C++ that's at the '}' of the block the variable is declared<br>> ><br>> >Cheers.<br>> ><br>> >Tim.<br>><br>> _______________________________________________<br>> LLVM Developers mailing list<br>> llvm-dev@lists.llvm.org<br>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote></div>