<div dir="auto"><div dir="auto">It was my reply only. I think my previous reply line was bit screwed up.<br></div><div dir="auto"><br></div><div dir="auto">Mahesha</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu 23 Sep, 2021, 10:32 AM Johannes Doerfert, <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 9/22/21 9:45 PM, Mahesha S wrote:<br>
> On Wed, Sep 22, 2021 at 10:04 PM Johannes Doerfert <<br>
> <a href="mailto:johannesdoerfert@gmail.com" target="_blank" rel="noreferrer">johannesdoerfert@gmail.com</a>> wrote:<br>
><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<br>
>> by<br>
>>> inserting control flow before static allocas. The doc you linked to seems<br>
>>> to cover that.<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<br>
>> 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<br>
>> 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<br>
>> will<br>
>> give people a strong incentive to follow that form :)<br>
>><br>
>> ~ Johannes<br>
><br>
><br>
>> Actually it is a gray area - On one hand, it is not an<br>
>> explicitly mandated/enforced requirement/rule since it cannot be, and on the<br>
>> other hand, such a canonical form is required for better code<br>
>> optimization/transformation.<br>
>><br>
Who said this? Did I miss an email?<br>
<br>
~ Johannes<br>
<br>
<br>
> Given this situation, I personally think that it is always better to<br>
> maintain the canonical form - In the worst case, all the static allocas<br>
> should be placed before any call, and in the best case, it is ideal to<br>
> maintain all static allocas at the top of the entry block as one cluster.<br>
><br>
> How do we maintain it is a next sequel question if we all agree to the<br>
> above required canonical form, and it all should start from the front-end.<br>
><br>
> PS:  Meanwhile, I have pushed a CFE patch in this attempt at -<br>
> <a href="https://reviews.llvm.org/D110257" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D110257</a><br>
><br>
> Thanks<br>
> Mahesha<br>
><br>
><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<br>
>> 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" rel="noreferrer">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<br>
>> 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 noreferrer" target="_blank">https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas</a><br>
>> after<br>
>>>> this discussion -<br>
>>>> <a href="https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html" rel="noreferrer 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" rel="noreferrer">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<br>
>> 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" rel="noreferrer">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<br>
>> 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<br>
>> 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<br>
>> 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" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
>>>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><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" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>