[llvm-dev] Placement of static allocas

Wed Sep 22 19:45:32 PDT 2021

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.
>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210923/611117c8/attachment.html>