similar to: [LLVMdev] Code Generation and Alloca

Dear All, Is it legal to have an alloca in a basic block other than a function's entry block? -- John T.

Hello, Ryan. > It seems as though, when the bytecode is disassebled, the result of the > allocas should be given as a parameter to the stores. It's given. > If the disassembler doesn't give the allocas a name, then that dependency is > not conveyed. Both disassembly & bytecode is correct. Please carefully read LLVM Language reference about %"num" names. --

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

> Why isn't llvm giving a name to the value returned by the allocas and > using it in the store instructions? Because you pass in an empty string for the name in the new AllocaInst calls below. Replace the empty strings with "argc_addr" or whatever you want. > AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "", >

Are there any implicit assumptions about where alloca instructions can appear. I've got a failing test where the only difference between a passing test 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

Thanks all. David why do you say it is particularly bad IR (other than not having gone through SROA). Is it the multiple blocks for early returns? That is how I'm supporting early returns in the middle of a basic block. I couldn't find any other way. On Sun, Apr 5, 2015 at 6:24 AM, David Jones <djones at xtreme-eda.com> wrote: > Data point: > > I use (rarely) alloca in

Hello Duncan, I compiled LLVM without optimizations (because maybe I have to look to memory accesses in the future). Maybe some of these optimizations I can enable when I am running my pass with opt ? It is still one thing that I don't understand. 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

On 27 Aug 2015, at 07:40, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Aug 26, 2015 at 8:25 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/26/2015 07:02 PM, Chandler Carruth via llvm-dev wrote: >> >> Without a better understanding of both the motivation and the resulting consequences such as what I've outlined

On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote: > Are there any implicit assumptions about where alloca instructions > can appear. Static allocas should appear as a continuous chunk in the entry block, otherwise other passes might make bad assumptions. > The interesting thing about this testcase is that the extra instcombine makes > the test pass.  If I

After looking at this problem longer, I believe that there is something wrong with the disassembler. When I run my transformation and then disassemble the output, I get bytecode that looks like: ----- int %main(int %argc, sbyte** %argv) { entry: alloca int ; <int*>:0 [#uses=3] alloca sbyte** ; <sbyte***>:0 [#uses=3] store int %argc,

It's not great IR, but it doesn't look like it should actually crash, just (without SROA) produce comparatively bad 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

Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this

Hi, > On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote: >> Are there any implicit assumptions about where alloca instructions >> can appear. > > Static allocas should appear as a continuous chunk in the entry block, > otherwise other passes might make bad assumptions. an alloca can appear anywhere, but when they are outside the entry block then

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

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

I have a compiler which generates a lot of malloc instructions for basically all data. I was rather hoping that these mallocs would be converted to allocas if the pointers didn't escape. This would require an escape analysis, and I'm not sure if LLVM has such a thing. For instance, consider this code (typical of the output of my compiler): define i32 @dontescape(i32 %x) { entry:   %t =

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

I'm trying to determine what is the best approach to using AllocA. Currently I just allocate all my variables at the beginning of the function but wondering if they should rather be done closer to the scope they are used. This would also require a way to do a free on the allocated structure, but there doesn't appear to be such a function. Is it the intent that all stack variables are

Here is some IR that is working and executing as expected -- All allocas are in the first basic block, and only updates happen in other basic blocks. define i32 @f() { entry: %x = alloca i32 store i32 333, i32* %x %i = alloca i32 store i32 11, i32* %i br i1 true, label %if.then, label %if.else if.then: ; preds = %entry store i32 3, i32* %i

And you really want your allocas in the entry block so they are implemented by just stack pointer manipulation rather than calling alloca(). The latter is slower, and there's also a bug that makes calling alloca() not getting the alignment right (if it's > 8). On Tue, Oct 13, 2009 at 9:44 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > >> On Mon, Oct 12, 2009