search for: allocas

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

...A dependence between the alloca instruction and the stackrestore instruction that prevents optimizers from accidentally reordering them in ways that don't verify. llvm.stacksave in this case is taking on a role similar to CALLSEQ_START in the selection dag. LLVM can also apply this to dynamic allocas from inline functions to ensure that optimizers don't move them. 2. Add an 'alloca' attribute for parameters. Only an alloca value can be passed to a parameter with this attribute. It cannot be bitcasted or GEPed. An alloca can only be passed in this way once. It can be passed as a...

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

...39;s anymore. The above method should work but has the inconvenience of generating lots of alloca/store/load instructions. That's is fine if you don't care too much about compilation time or readability of the unoptimized LLVM IR code. My translator uses general LLVM values instead of just allocas, so code like this: a := (b + c) * d that would translate to this with the alloca method: (b, c and d are values already on the stack) # pop the alloca for b # pop the alloca for c # generate LLVM load (for b) # generate LLVM load (for c) # generate LLVM instruction for b + c # create LLVM allo...

...c=a+7000*b[32], Load(c)...ICMP(c, ...) > > > > I want to get the corresponding Alloca from every Load > > (corresponding from the point of view of the variable used, > > meaning that the Load is using a variables based/dependent on the Alloca > or Allocas). > > I don't know any magical LLVM way to get all the answers. > My approach would be to do some ordinary data-flow analysis, > chasing back along def-use chains to find instructions that define > the registers used in the load, recursively, to the beginning. &gt...

I'm translating the source of stack-based virtual machine into LLVM IR and my plan is to implement the stack in LLVM IR (using alloca/load/store) in order to emulate the VM's stack and then use the optimization phase "mem2reg". Therefore I'm going to have a stack pointer that points to the top of my stack. I'm curious whether I will have to implement that in a

...te: > 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, but in general it is simpler to have the >> front-end just put >> them there in the first place. >> >> >> Mem2reg is already changing that semantic, though. If I use an >> "alloca i32" in &...

...tand. If the memory accesses will be eliminated, and I have the following situation: %i = alloca i32, align 4 %j = alloca i32, align 4 ..... %2 = load i32* %i, align 4 %3 = load i32* %j, align 4 %add = add nsw i32 %2, %3 %cmp2 = icmp sgt i32 %add, 2 How can I check that %cmp2 is dependent on both allocas? Sorry if the question was asked without any testing with optimizations enabled. Basically, my plan is : if (Inst->getOpcode()==Instruction::Load) { LoadInst *LD10 = cast<LoadInst>(Inst); Value *C10 = LD10->getPointerOperand(); } so I get all the good allocas...

According to comment in tree-nested.c, these frames should be only introduced in case of debug or OpenMP lowering: /* A subroutine of convert_nonlocal_reference_op. Create a local variable in the nested function with DECL_VALUE_EXPR set to reference the true variable in the parent function. This is used both for debug info and in OpenMP lowering. */ However, in this code example we

...code. The alloca is only referenced in the basic block that it exists. If this isn't expected to work, then we should probably improve the documentation of alloca in the language reference. David > On 5 Apr 2015, at 04:55, Eric Christopher <echristo at gmail.com> wrote: > > Allocas not in the entry block are treated as dynamic allocas and not stack slots. > > > On Sat, Apr 4, 2015, 8:37 PM Dave Pitsbawn <dpitsbawn at gmail.com> wrote: > Here is some IR that is working and executing as expected -- All allocas are in the first basic block, and only updates h...

How do you handle this during codegen? One problem is avoid stack changes (like spills). Another is coordinating things that are using allocas and those that are not but end up in the stack. Consider void foo(int arg1, int arg2, int arg3, ....CXXTypeWithCopyConstructor argn, int argp1...) You will need an alloca for argn, but the ABI also requires it to be next to the plain integers that didn' fit in registers, no? This is part of t...

Full_Name: Eric van Gyzen Version: 2.1.0 OS: FreeBSD 5.4 Submission from: (NULL) (152.3.22.33) R-2.1.0 fails to compile on the newest release of FreeBSD, complaining about undefined references to __builtin_alloca. On FreeBSD, alloca() is declared in stdlib.h, not alloca.h as the R sources expect. Therefore, HAVE_DECL_ALLOCA does not get set, so the R sources declare alloca() after it has

I want to insert new alloca Instruction after existing alloca Instruction in llvm pass so what attribute to be passed at last in following newallocaI = new AllocaInst(llvm::Type::getInt32PtrTy(context,0), //type 0, // ArraySize 8, // Alignment

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

...6, 2013 at 5:42 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Vinod, > > > On 23/02/13 02:20, Vinod Grover wrote: > >> Sorry if this has been discussed before, but I would appreciate any >> pointers. >> I am trying to understand why mem2reg only looks at allocas in entry >> blocks, and >> not for any allocas in a function. One case where allocas could be used >> to build >> local data structures like linked list (and so on make it unsafe), and >> for that >> the existing conditions in IsAllocaPromotable (i.e. the alloca...

In 3.1, the backend is very slow to legalize types. Following is the code snippet which may be the culprit: %Result.i.i.i97 = alloca i33, align 8 %Result.i.i.i96= alloca i33, align 8 %Result.i.i.i95 = alloca i33, align 8 %Result.i.i.i94 = alloca i33, align 8 %Result.i.i.i93 = alloca i33, align 8 %Result.i.i.i92= alloca i33, align 8 %Result.i.i.i91 = alloca i33, align 8

...t and a failing test is one application of this code in instcombine: // Convert: malloc Ty, C - where C is a constant != 1 into: malloc [C x Ty], 1 Seems pretty harmless to me. Later on the instcombine code does this: // Scan to the end of the allocation instructions, to skip over a block of // allocas if possible... That comment makes me a bit suspicious regarding assumptions about alloca placement. The interesting thing about this testcase is that the extra instcombine makes the test pass. If I omit it, the test fails. The only differences in the asm are stack offsets, which leads me to b...

To what do variable size LLVM alloca instructions get translated, when they are turned into machine code? I compiled a piece of code to bitcode and disassembled it. The disassembled code showed that there were alloca instructions with variable-sized parameters within the bitcode. When I turned the bitcode into machine code, I performed an nm on the result but didn't see any symbols

...nged = means that : > I might have Alloca(a), c=a+7000*b[32], Load(c)...ICMP(c, ...) > > I want to get the corresponding Alloca from every Load > (corresponding from the point of view of the variable used, > meaning that the Load is using a variables based/dependent on the Alloca or Allocas). I don't know any magical LLVM way to get all the answers. My approach would be to do some ordinary data-flow analysis, chasing back along def-use chains to find instructions that define the registers used in the load, recursively, to the beginning. If you hit an alloca, stop. > I tried t...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AFAIK, alloca.h is not POSIX. Here's a patch that includes alloca.h only when it's really there. It also includes malloc.h, which is where mingw-w64 defines the alloca() macro, mapping it to gcc __builtin_alloca() or to msvcrt _alloca(). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: