<div dir="ltr"><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"><span style="font-family:Arial,Helvetica,sans-serif">On Wed, Sep 22, 2021 at 10:04 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 9/22/21 10:37 AM, Reid Kleckner via llvm-dev wrote:<br>
> Frontends should place allocas in the entry block, and importantly, they<br>
> should appear before any instruction that can later expand into control<br>
> flow, such as an inlinable function call. Passes should not pessimize IR by<br>
> inserting control flow before static allocas. The doc you linked to seems<br>
> to cover that.<br>
<br>
The interesting part is not as much control flow as it is non-alloca<br>
instructions because control flow already breaks our current "canonical <br>
form".<br>
<br>
So, do we want to say that allocas should not be interleaved with any<br>
other instruction in the entry block (in our canonical form), or should<br>
we say that canonical form is "just" requiring them to be in the entry.<br>
We only do the latter explicitly today. Some FEs and passes insert code<br>
in-between allocas, e.g. as-casts or debug metadata. I'd also not be <br>
surprised<br>
if we find more cases that insert a cast or similar before an alloca.<br>
<br>
One way to determine how different those two are in practice would be to<br>
stop scanning the entire entry block in SROA. Any non-clustered alloca won't<br>
easily be promoted and show up as a blip in our monitoring.<br>
<br>
I personally don't feel strongly here though I imagine the currently written<br>
down canonical form is simpler to maintain. Clustered static allocas can be<br>
created for all static allocas with a simple scan+move over the entry. I <br>
think<br>
maintaining clustered allocas is unnecessarily hard is because passes that<br>
introduce casts (or similar) need to have a special check for the <br>
alloca/entry<br>
block case. That said, it's not impossible.<br>
<br>
Long story short, I feel SROA should define the canonical form here. It will<br>
give people a strong incentive to follow that form :)<br>
<br>
~ Johannes</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="trebuchet ms, sans-serif">Actually it is a gray area - On one hand, it is not an explicitly mandated/enforced requirement/rule since it cannot be, </font><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">and on </span><font face="trebuchet ms, sans-serif">the other hand, such a </font><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"></span><font face="trebuchet ms, sans-serif">canonical form is required for better code optimization/transformation.</font><br></blockquote><div> </div><div><span style="font-family:"trebuchet ms",sans-serif">Given this situation, <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">I personally think that i</span>t is <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">always </span>better <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">to </span>maintain <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">the </span></span><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></span><font face="trebuchet ms, sans-serif">canonical form</font><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"> - In the worst case, all the static allocas should be placed before any call, and in the best case, it is ideal to maintain all static allocas at the top of the entry block as one cluster.</span><br></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">How do we maintain it is a next </span></span><font face="trebuchet ms, sans-serif">sequel<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"> question if we all agree to the above required canonical form, and it all should start from the front-end.</span></font></div><div><font face="trebuchet ms, sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small"><br></span></font></div><div><font face="trebuchet ms, sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">PS:  Meanwhile, I have pushed a CFE patch in this attempt at - </span><a href="https://reviews.llvm.org/D110257">https://reviews.llvm.org/D110257</a></font></div><div><font face="trebuchet ms, sans-serif"><br></font></div><div>T<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">hanks</span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif;font-size:small">Mahesha</span> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> As far as rules go, this is not something that the verifier can enforce,<br>
> because static allocas don't carry a special "static" marker. The static<br>
> property is determined simply by the placement of the instruction. There is<br>
> the `inalloca` marker, but that's not relevant here.<br>
><br>
> On Tue, Sep 21, 2021 at 9:55 AM Mahesha S via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> As I understand it, the verifier does not complain about the<br>
>> (mis-)placement of alloca, probably because it is not something related to<br>
>> correctness (in theory), but it is related to optimization opportunities<br>
>> (in practice).<br>
>><br>
>> I could see this documentation -<br>
>> <a href="https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas" rel="noreferrer" target="_blank">https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas</a> after<br>
>> this discussion -<br>
>> <a href="https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html</a>.<br>
>> But, nothing more on it.<br>
>><br>
>> So not sure about - what is the general rule being set on placement of<br>
>> static allocas?, or, if there is any such rule in the first place? or,<br>
>> front-end and opt passes are free about the placement of static allocas?<br>
>><br>
>> Thanks,<br>
>> Mahesha<br>
>><br>
>><br>
>> 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>
>><br>
>>> IIRC you can interleave debug intrinsics (e.g. llvm.dbg.declare) with<br>
>>> alloca instructions (at least the verifier doesn't complain). Not sure if<br>
>>> there are other intrinsics that fall into this category as well.<br>
>>><br>
>>> -Min<br>
>>><br>
>>> On Tue, Sep 21, 2021 at 7:45 AM Mahesha S via llvm-dev <<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>>> Hi-<br>
>>>><br>
>>>> Here is my understanding and assumption about the placement of static<br>
>>>> allocas:<br>
>>>><br>
>>>> "All static allocas should appear in the entry basic block before any<br>
>>>> function call for better optimization opportunities. If there are<br>
>>>> interleaved static allocas with function call in-between, such an ir is<br>
>>>> considered broken, even though the ir is valid from correctness<br>
>>>> perspective. And if any pass is not adhering to the requirement that all<br>
>>>> static allocas should be placed in the entry block before any function<br>
>>>> call, then such a pass is considered broken since it may lead to surprising<br>
>>>> results in general."<br>
>>>><br>
>>>> Let me know if my above understanding is correct or not.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Mahesha<br>
>>>> _______________________________________________<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>
>>>><br>
>>><br>
>>> --<br>
>>> Min-Yih Hsu<br>
>>> Ph.D Student in ICS Department, University of California, Irvine (UCI).<br>
>>><br>
>> _______________________________________________<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>
>><br>
><br>
> _______________________________________________<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></div></div></div></div>