<div dir="ltr"><div>Frontends should place allocas in the entry block, and importantly, they should appear before any instruction that can later expand into control flow, such as an inlinable function call. Passes should not pessimize IR by inserting control flow before static allocas. The doc you linked to seems to cover that.</div><div><br></div><div>As far as rules go, this is not something that the verifier can enforce, because static allocas don't carry a special "static" marker. The static property is determined simply by the placement of the instruction. There is the `inalloca` marker, but that's not relevant here.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 9:55 AM Mahesha S via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">As I understand it, the verifier does not complain about the (mis-)placement of alloca, probably because it is not something related to correctness (in theory), but it is related to optimization opportunities (in practice). </div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">I could see this documentation - <a href="https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas" target="_blank">https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas</a> after this discussion - <a href="https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html</a>. But, nothing more on it.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">So not sure about - what is the general rule being set on placement of static allocas?, or, if there is any such rule in the first place? or, front-end and opt passes are free about the placement of static allocas?</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">Thanks,<br></div><div><div dir="ltr"><div dir="ltr"><div><font face="trebuchet ms, sans-serif">Mahesha</font></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 9:56 PM Min-Yih Hsu <<a href="mailto:minyihh@uci.edu" target="_blank">minyihh@uci.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">IIRC you can interleave debug intrinsics (e.g. llvm.dbg.declare) with alloca instructions (at least the verifier doesn't complain). Not sure if there are other intrinsics that fall into this category as well.<div><br></div><div>-Min</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 21, 2021 at 7:45 AM Mahesha S via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">Hi-</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">Here is my <span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">understanding and</span><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"> assumption about the placement of static allocas:</span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">"All static allocas should appear in the entry basic block before any function call for better optimization opportunities. If there are interleaved static allocas with function call in-between, such an ir is considered broken, even though the ir is valid from correctness perspective. And if any pass is not adhering to the requirement that all static allocas should be placed in the entry block before any function call, then such a pass is considered broken since it may lead to surprising results in general."</span><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">Let me know if my above understanding is correct or not.</span><span style="color:rgb(0,0,0);font-family:"Segoe UI","Segoe UI Emoji","Segoe UI Symbol",Lato,"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></div><div><div dir="ltr"><div dir="ltr"><font face="trebuchet ms, sans-serif">Thanks,</font><div><font face="trebuchet ms, sans-serif">Mahesha</font></div></div></div></div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Min-Yih Hsu</div><div>Ph.D Student in ICS Department, University of California, Irvine (UCI).<br></div></div></div>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>