[llvm-dev] Placement of static allocas

Wed Sep 22 22:02:11 PDT 2021

On 9/22/21 9:45 PM, Mahesha S wrote:
> On Wed, Sep 22, 2021 at 10:04 PM Johannes Doerfert <
> johannesdoerfert at gmail.com> wrote:
>
>> On 9/22/21 10:37 AM, Reid Kleckner via llvm-dev wrote:
>>> 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.
>> The interesting part is not as much control flow as it is non-alloca
>> instructions because control flow already breaks our current "canonical
>> form".
>>
>> So, do we want to say that allocas should not be interleaved with any
>> other instruction in the entry block (in our canonical form), or should
>> we say that canonical form is "just" requiring them to be in the entry.
>> We only do the latter explicitly today. Some FEs and passes insert code
>> in-between allocas, e.g. as-casts or debug metadata. I'd also not be
>> surprised
>> if we find more cases that insert a cast or similar before an alloca.
>>
>> One way to determine how different those two are in practice would be to
>> stop scanning the entire entry block in SROA. Any non-clustered alloca
>> won't
>> easily be promoted and show up as a blip in our monitoring.
>>
>> I personally don't feel strongly here though I imagine the currently
>> written
>> down canonical form is simpler to maintain. Clustered static allocas can be
>> created for all static allocas with a simple scan+move over the entry. I
>> think
>> maintaining clustered allocas is unnecessarily hard is because passes that
>> introduce casts (or similar) need to have a special check for the
>> alloca/entry
>> block case. That said, it's not impossible.
>>
>> Long story short, I feel SROA should define the canonical form here. It
>> will
>> give people a strong incentive to follow that form :)
>>
>> ~ Johannes
>
>
>> Actually it is a gray area - On one hand, it is not an
>> explicitly mandated/enforced requirement/rule since it cannot be, and on the
>> other hand, such a canonical form is required for better code
>> optimization/transformation.
>>
Who said this? Did I miss an email?

~ Johannes


> Given this situation, I personally think that it is always better to
> maintain the canonical form - 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.
>
> How do we maintain it is a next sequel question if we all agree to the
> above required canonical form, and it all should start from the front-end.
>
> PS:  Meanwhile, I have pushed a CFE patch in this attempt at -
> https://reviews.llvm.org/D110257
>
> Thanks
> Mahesha
>
>
>>> 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.
>>>
>>> On Tue, Sep 21, 2021 at 9:55 AM Mahesha S via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> 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).
>>>>
>>>> I could see this documentation -
>>>> https://llvm.org/docs/Frontend/PerformanceTips.html#use-of-allocas
>> after
>>>> this discussion -
>>>> https://lists.llvm.org/pipermail/llvm-dev/2015-September/090191.html.
>>>> But, nothing more on it.
>>>>
>>>> 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?
>>>>
>>>> Thanks,
>>>> Mahesha
>>>>
>>>>
>>>> On Tue, Sep 21, 2021 at 9:56 PM Min-Yih Hsu <minyihh at uci.edu> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> -Min
>>>>>
>>>>> On Tue, Sep 21, 2021 at 7:45 AM Mahesha S via llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hi-
>>>>>>
>>>>>> Here is my understanding and assumption about the placement of static
>>>>>> allocas:
>>>>>>
>>>>>> "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."
>>>>>>
>>>>>> Let me know if my above understanding is correct or not.
>>>>>>
>>>>>> Thanks,
>>>>>> Mahesha
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>> --
>>>>> Min-Yih Hsu
>>>>> Ph.D Student in ICS Department, University of California, Irvine (UCI).
>>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev