similar to: [LLVMdev] Alloca Outside of Entry Block

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

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

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,

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 Tue, Feb 26, 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

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

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

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.

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

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 pointer cannot

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

We don't have any such optimization. Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not difficult. We do similar analysis to determine pointer capture already. Matt Giuca wrote: > I have a compiler which generates a lot of malloc instructions for

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 =

Hi, I'm incrementing my toy compiler to account for variable mutations around if/else blocks. Reading the Kaleidoscope tutorial, I've learnt that I can substitute the PHI node creation by allocas and retrieving the value later, if needed. The Kaleidoscope example seems to account for one value only, the result of: Value *ThenV = Then->Codegen(); (...) Value *ElseV =

On Thu, May 15, 2014 at 9:31 AM, Philip Reames <listmail at philipreames.com>wrote: > On 05/14/2014 06:02 PM, Akira Hatanaka wrote: > > I would like to get feedback from the community on how I can speed up > the compilation of a function that has one huge basic block consisting of > over 150K instructions. It takes about 10 minutes for clang to produce the > object file

Hi, Consider this code: *** typedef struct _largestruct { char a[1019]; } t_largestruct; extern t_largestruct funclarge(void); int test(void) { char c; c=funclarge().a[0]; c+=funclarge().a[1]; return c; } *** When compiled for Darwin/x86_86 with either Clang or GCC and LLVM 2.7, the frontends (via alloca) and subsequently LLVM (on the cpu stack) allocate two separate temps for the

----- Original Message ----- > From: "Reid Kleckner via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 8, 2016 7:05:44 PM > Subject: [llvm-dev] RFC: Adding argument allocas > Clang is currently missing some low-hanging performance and code size > opportunities when receiving

I don't think licm looks at loads/stores to allocas -- these are usually handled by mem2reg which happens much earlier (if you run your example with -mem2reg you'll see it already deleted the store). In fact, licm sinks the stores by converting them to stores to allocas first and running mem2reg on that. If you change your example to void testLICM(int* restrict p) { int i,N=100;

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