[llvm-dev] A pass which moves AllocaInst into function entry block?

Johnson, Nicholas Paul via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 5 13:21:36 PST 2017

This was with clang.  Indeed llvm tries to move allocas to the entry block during function inlining, but in this case (for whatever reason) the alloca was not moved at that time.  Perhaps it was not an obviously safe transformation at inlining time, but became obviously safe after subsequent optimization cleared the way…

Since I first posted this question, I wrote and tested a simple pass that performs the transformation.  I run it before SROA.  That solves my problem.

Nick Johnson
D. E. Shaw Research

From: mats.o.petersson at googlemail.com [mailto:mats.o.petersson at googlemail.com] On Behalf Of mats petersson
Sent: Thursday, January 05, 2017 12:51 PM
To: Johnson, Nicholas Paul
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] A pass which moves AllocaInst into function entry block?

In my compiler, I wrote code to always put alloca at the entry of a function (basically, "figure out current function, find first basic block, insert alloca into the bb").

Is this for your own compiler, for clang, or something other use? [I was under the impression that clang did this too, but I may be wrong]


On 5 January 2017 at 16:47, Johnson, Nicholas Paul via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Is there an existing LLVM pass which moves alloca instructions into the function entry block?  In particular, I am seeing an alloca which is ideal for this movement: the alloca is not in the function entry block, it allocates a constant size, it is *not* within a loop, and it is in a block which post-dominates the function entry (i.e., it invariably executes with every function invocation).

I think this movement normally happens as during the function inlining process.  I'm not sure why it hasn't occurred in this case, but whatever the reason, the poor alloca placement inhibits later optimizations, especially SROA, so I would like to fix it.

Nick Johnson
D. E. Shaw Research

LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170105/0212be66/attachment.html>

More information about the llvm-dev mailing list