search for: geped

Hi, Is there a way in llvm IR to emit multiple data elements within a single compilation unit that a) are guaranteed to appear sequentially in the final binary (in the order they appear in the llvm IR), and b) will be removed on an individual basis by the optimizers and/or linker in case they are not referenced from anywhere ? Defining them as "appending" puts them all into a

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Louis Gerbarg" <lgg at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, May 22, 2014 7:09:49 PM > Subject: Re: [LLVMdev] RFC: Indexing of structs vs arrays in getelementpointer > > > > >

...LSEQ_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 normal pointer to any number of other functions. Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, there can be no allocas between the creation of an alloca passed with this attribute and its associated...

Hi, Daniel Berlin wrote: > Then the original reported code is fine, and the bug is in llvm or > llvm-gc (IE Owen is wrong) There is, actually, no problem with this example. I attached it, because it contains some specific programming technique, for which, after instcombining, a weird GEP is generated. I've pasted fragments of generated assembly code below, if someone is interested.

On Feb 25, 2009, at 12:12 PM, Stefanus Du Toit wrote: >> Although, I'm not completely sure the transformation is safe, at >> least >> the way you're stating it; unlike add, GEP has undefined overflow, so >> this isn't right in cases like %call == %tmp4 == INT_MIN. > > Hmm, you raise a good point. There's a similar issue even without > overflow,

On 11/15/07, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > Sadly, this will break a very common idiom. In GCC, we discovered it > > to be common enough that it broke a *bunch* of C code. > > > > In particular, you will break > > > > struct foo { > > int a; > > char name[0]; > > } > > > > bar = malloc(sizeof

...> 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 normal pointer to any number of other functions. > > Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, there > can be no allocas between the creation of an alloca passed with this attribute...

On 01/08/14 19:37, Reid Kleckner wrote: > What happens if you drop appending linkage? I think it will just work, > since you are already using a custom section, which will ensure that all > the data appears contiguously in memory. Thanks for the suggestion, but it still puts everything in a single .section statement. > Although, I do worry about what LLVM's alias analysis will

...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 normal pointer to any number of other functions. > > Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, > there > can be no allocas between the creation of an alloca passed with this...

...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 normal pointer to any number of other functions. > > Aside from allocas bounded by llvm.stacksave and llvm.stackrestore calls, > there > can be no allocas between the creation of an alloca passed with this...

On 30-Jan-09, at 6:14 PM, Eli Friedman wrote: > On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit > <stefanus.dutoit at rapidmind.com> wrote: >> The computation of %base then becomes loop-invariant and can be >> lifted out. >> >> What's the best way to add this optimization to LLVM? > > Probably the best place is LICM itself... only loop