search for: geping

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

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, 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

Hi Reid, On 25/07/13 23:38, Reid Kleckner wrote: > 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

...ustom 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 say about > this... I don't think LLVM allows GEPing from one global to another, and > at the end of the day, you'll GEP from an external global representing > the section start through to the elements of the array to section end. That's true and an interesting point. However, wouldn't that mean that "appending" linkage...

I wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll

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

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