similar to: [LLVMdev] Alloca Outside of Entry Block

On Aug 13, 2008, at 10:49 AM, John Criswell wrote: > Is it legal to have an alloca in a basic block other than a > function's entry block? How else could you generate code for: #include <stdlib.h> void *vp; size_t foo(int); void watch(void *); void* bar(int i) { if (i) vp = alloca(foo(i)); watch (vp); } ? The answer should be yes.

John Criswell wrote: > Dear All, > > Is it legal to have an alloca in a basic block other than a function's > entry block? > Thanks everyone for the answers. My original question was referring to the LLVM IR and not standard C. So, the consensus seems to be that it is legal, which makes sense since LLVM supports the C alloca function. FWIW, I'm not inserting allocas

This is the right answer for C's alloca. The question probably referred to LLVM IR's alloca, however. On Aug 13, 2008, at 11:07 AMPDT, Mike Stump wrote: > On Aug 13, 2008, at 10:49 AM, John Criswell wrote: >> Is it legal to have an alloca in a basic block other than a >> function's entry block? > > How else could you generate code for: > > #include

On Thu, Aug 14, 2008 at 7:55 AM, John Criswell <criswell at uiuc.edu> wrote: > Thanks everyone for the answers. My original question was referring to > the LLVM IR and not standard C. > > So, the consensus seems to be that it is legal, which makes sense since > LLVM supports the C alloca function. Yeah, legal, but the performance sucks because it codegens into a call to the

The Kaleidoscope example here: http://llvm.org/docs/tutorial/LangImpl7.html#adjustments defines a CreateEntryBlockAlloca() helper function that "ensures that the allocas are created in the entry block of the function." It's kid of implied, but I thought I'd ask explicitly: *must* alloca instructions be created in the entry block of a function? - Paul

On 3/29/12 11:32 AM, Paul J. Lucas wrote: > The Kaleidoscope example here: > > http://llvm.org/docs/tutorial/LangImpl7.html#adjustments > > defines a CreateEntryBlockAlloca() helper function that "ensures that the allocas are created in the entry block of the function." > > It's kid of implied, but I thought I'd ask explicitly: *must* alloca instructions be

My understanding is that it is legal to have allocas in any basic block. However, the mem2reg pass only recognizes allocas in the entry block of a function as candidate for conversion into registers. So if you're hoping to use mem2reg, it won't work if you place your allocas elsewhere. -Srikumar

Dear All, I have a question regarding code generation and alloca. How important is it to keep allocas in a function's entry block consecutive? Having consecutive allocas probably makes code generation more efficient because the code generator can coalesce them into a single add/subtract of the stack pointer on function entry. Can the code generators now coalesce allocas even if they

Hi, My recent refactoring of the (machine-dependent) use of <alloca.h> does not attempt to change CWriter's behavior of emitting a #include for <alloca.h>. FreeBSD does not have <alloca.h>, so this would cause trouble. We could change it to emit an #ifndef __FreeBSD__...#endif around #include <alloca.h>. I suggest this because, I'm guessing, whether or not the

Hi everyone, We have noticed that the SROA pass will only eliminate 'alloca' instructions if those are located in the entry basic block of a function. As a general recommendation, should the LLVM IR emitted by our compiler always place 'alloca' instructions in the entry basic block ? (I couldn't find any recommendations concerning this matter.) In addition, we have noticed

Hi As shown below, the .\configure script found a version of alloca(): --------------------- configure:20831: checking for working alloca.h configure:20853: gcc -o conftest -g -O2 conftest.c -ldl >&5 configure:20856: $? = 0 configure:20859: test -s conftest configure:20862: $? = 0 configure:20873: result: yes configure:20883: checking for alloca configure:20925: gcc -o conftest -g -O2

On 2/26/13 8:06 AM, Duncan Sands wrote: > Hi Justin, > >> an alloca outside of the entry block might be inside a loop, in >> which case the >> semantics are that it would allocate more stack space on every >> loop iteration. >> I think some of the optimizers that run later try to move allocas >> into the entry >> block if possible,

Dear All, I have, in an LLVM bitcode program, the following phi node: %iftmp.225.0 = phi i8* [ getelementptr ([10 x i8]* @.str12597431, i32 0, i32 0), %bb114 ], [ getelementptr ([10 x i8]* @.str1258, i32 0, i32 0), %bb111 ], [ getelementptr ([10 x i8]* @.str1258, i32 0, i32 0), %bb111 ] This phi instruction has two arguments for the same incoming basic block. The only reason why it passes

Tanu Sharma wrote: > Hello, > > In an attempt to randomise the basic blocks in a function, is it > possible that I can randomise the entry block as well? And maybe insert > some instructions in the pass to call entry block while running the > program ? > > Is it feasible? > > What does entry block consist of ? The entry block, by definition, is the first basic

On 1/21/13 5:22 AM, Alexandru Ionut Diaconescu wrote: > Hello everyone ! > > I am trying to determine for certain Load instructions from my pass > their corresponding Alloca instructions (that can be in other previous > blocks). The chain can be something like : `TargetLoad(var) -> other > stores/loads that use var (or dependencies on var) -> alloca(var).` , > linked

On Mon, 2003-06-16 at 17:33, John Criswell wrote: > What would be better yet is to modify the code so that it does not use > alloca() at all. There seems to be little reason to use it aside from > convenience (but perhaps I have missed something). I think the idea is that alloca can give (probably significant) performance gains when used properly. In the cases where you need

Hello everyone ! I am trying to determine for certain Load instructions from my pass their corresponding Alloca instructions (that can be in other previous blocks). The chain can be something like : `TargetLoad(var) -> other stores/loads that use var (or dependencies on var) -> alloca(var).` , linked on several basic blocks. Do you know how can I do it? I tried to use the methods from

Thanks a lot for replying. I have another query. If branching to the entry block is not legal in llvm how should I be able to create a new entry block for any existing list? I created a new block and inserted it into the present basic block list , but I get this error: opt: BasicBlock.cpp:83: virtual llvm::BasicBlock::~BasicBlock(): Assertion `getParent() == 0 && "BasicBlock

On 12/2/11 3:24 PM, Eli Friedman wrote: > On Fri, Dec 2, 2011 at 1:04 PM, John Criswell<criswell at illinois.edu> wrote: >> Dear All, >> >> Is there an optimization in the x86 back-end that could cause two >> alloca's to use overlapping memory? > It's theoretically possible, but IIRC there isn't any such > optimization implemented at the moment.

On Mar 17, 2009, at 11:37 AMPDT, John Criswell wrote: > Dear All, > > I have, in an LLVM bitcode program, the following phi node: > > %iftmp.225.0 = phi i8* [ getelementptr ([10 x i8]* @.str12597431, > i32 0, > i32 0), %bb114 ], [ getelementptr ([10 x i8]* @.str1258, i32 0, i32 > 0), > %bb111 ], [ getelementptr ([10 x i8]* @.str1258, i32 0, i32 0), > %bb111 ]