[llvm-dev] Alloca, Inlining and Entry Basic Block

Roman Lebedev via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 14 05:22:35 PDT 2021


On Tue, Sep 14, 2021 at 2:49 PM Mahesha S via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi-
>
> Theoretically, alloca instructions can appear anywhere within the function body, but practically, it is better to keep them as a one cluster at the beginning of the entry basic block for better optimization opportunities.

> And, I think the front-end code gen phase mostly succeeds in clustering all alloca instructions at the beginning of the entry basic block. Nevertheless, it is not guaranteed always. One more case is inlining - which may leave alloca instructions other than in entry block.
*May*? Can you show an example perhaps?
I would think that could only happen for VLA's,
because such an alloca can not be hoisted
to before it's length is calculated.

> So, I am thinking of adding a new late IR pass (after inlining) which deliberately moves all allocas which appear elsewhere to the beginning of the entry block.
>
> Now my questions are:
>
> (1) Can we neatly implement this pass? For example, what would happen if an alloca which appears within a loop is moved to the entry block?
> (2) Is there a possibility where some other later pass(es) other than inlining also can result in inserting alloca elsewhere, so the new proposed pass needs to be invoked multiple times?
>
> The main reason for the above ask is - I have my own doubt that if moving alloca to the entry block is such an easy task why not anyone from the community did not attempt it till date considering the importance of keeping the allocas at the beginning of the entry block for better optimization opportunities. If there are genuine reason for that, it is better to know it instead of blindly attempting to implement the pass.
>
> Thanks,
> Mahesha
Roman

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list