similar to: [LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray)

On May 14, 2009, at 4:56 AM, Jay Foad wrote: > 2009/4/1 Chris Lattner <clattner at apple.com>: >> As far API design goes, we're in a mixed state. I'd strongly prefer >> to get rid of std::vector from the various interfaces, f.e. >> creating a >> constant array currently requires passing in an std::vector. For >> these sorts of interfaces, we

> 3. Any comments on the patch itself? > > The one major thing to be aware of is that it isn't safe to use &V[0] when V > is an empty std::vector Oh dear. That's a bit of a flaw in the plan. I suppose the solution is to switch to SmallVector whenever this might be a problem. I'm a bit concerned that any new &empty[0] problems that are introduced will go unnoticed.

On Friday 15 May 2009 05:50, Jay Foad wrote: > > 3. Any comments on the patch itself? > > > > The one major thing to be aware of is that it isn't safe to use &V[0] > > when V is an empty std::vector > > Oh dear. That's a bit of a flaw in the plan. I suppose the solution is > to switch to SmallVector whenever this might be a problem. Or use iterators.

On 2009-05-15, at 07:26, David Greene wrote: > On Friday 15 May 2009 05:50, Jay Foad wrote: >> > >>> The one major thing to be aware of is that it isn't safe to use >>> &V[0] when V is an empty std::vector >> >> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >> is to switch to SmallVector whenever this might be a

On May 15, 2009, at 10:52 AM, Gordon Henriksen wrote: > On 2009-05-15, at 07:26, David Greene wrote: > >> On Friday 15 May 2009 05:50, Jay Foad wrote: >>> >> >>>> The one major thing to be aware of is that it isn't safe to use >>>> &V[0] when V is an empty std::vector >>> >>> Oh dear. That's a bit of a flaw in the

Thanks, Just one question more: why does Constant::getVectorElements() operate on a SmallVector<T>, while ConstantArray::get() operate on a std::vector<T> ? What is the distinction between these uses? Thanks! Nick On Tue, Mar 31, 2009 at 7:49 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 31, 2009, at 4:42 PM, Nick Johnson wrote: > >> Hello,

Hello, I need to append something to the global "llvm.global_ctors". This variable may or may not already be declared within the current module. If I lookup the global variable, I see that it supports a getOperand(i) and setOperand(i,c), but does not support any way that I can enlarge that array to add a new record. Any suggestions? -- Nick Johnson

On Mar 31, 2009, at 4:42 PM, Nick Johnson wrote: > Hello, > > I need to append something to the global "llvm.global_ctors". This > variable may or may not already be declared within the current module. > > If I lookup the global variable, I see that it supports a > getOperand(i) and setOperand(i,c), but does not support any way that I > can enlarge that array to

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

OK here's a new version of the patch - and the unions.ll test actually passes :) On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK here's the patch for real this time :) >> >> On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: >> Here's a work

I've made all the suggested changes - however, I'm having a bit of problem running the tests. I started "make check" and several hours later it had only made it through about 1/3 of the tests. I'm not sure what the deal is. On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK

OK here's the patch for real this time :) On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test "union.ll" > does not work, so you probably don't want to check this in as is. However, > I'd be interested in any feedback you're willing to give. > > -- > -- Talin

Here's a work in progress of the union patch. Note that the test "union.ll" does not work, so you probably don't want to check this in as is. However, I'd be interested in any feedback you're willing to give. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

The methods for constructing constant sequencish types (struct, array, vector) aren't consistent and we are missing a few useful convenience methods. I would like to change the interfaces to each support four construction methods: (a) With and without a type. (b) With a vector or an array + size. Here: -- ConstantStruct { static Constant *get(const StructType *T,

ping... On Thu, Jan 28, 2010 at 12:25 PM, Talin <viridia at gmail.com> wrote: > OK here's a new version of the patch - and the unions.ll test actually > passes :) > > On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Jan 16, 2010, at 11:15 AM, Talin wrote: >> >> OK here's the patch for real this

On Sat, Jan 19, 2013 at 8:33 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > There isn't much use of std::string in LLVM because it's simply not > needed. There's very little string manipulation, so StringRef is often > a much better choice. When there is a need for string manipulation, > the strings are generally very short, so SmallString is better.

When I build LLVM with ENABLE_EXPENSIVE_CHECKS=1, make check fails: Running /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/dg.exp ... FAIL: /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /home/foad/svn/llvm-project/llvm/trunk/test/CodeGen/ARM/2007-05-14-InlineAsmCstCrash.ll | llc

On 1/19/2013 7:55 PM, Sean Silva wrote: > > Although SmallString is actually pretty inefficient, since it keeps > the string data separate from the "vector" header. I believe libc++'s > std::string actually reuses the pointers in the "vector header" as the > storage for the "small" size, and so in that case std::string is > effectively a very

I notice that there's a lot of inconsistency in the various LLVM classes with respect to convenience methods. Here's some examples: For creating GEPS, IRBuilder has: CreateGEP (2 overloads) CreateInBoundsGEP (2 overloads) CreateConstGEP1_32 CreateConstInBoundsGEP1_32 CreateConstGEP2_32 CreateConstInBoundsGEP2_32 CreateConstGEP1_64 CreateConstInBoundsGEP1_64

Hi all; I have been trying to use the llvm::ConstantArray::get(llvm::LLVMContext&, llvm::StringRef, bool) function but seems it has been deprecated. ProfileDependence.cpp:68:73: error: no matching function for call to ‘llvm::ConstantArray::get(llvm::LLVMContext&, llvm::StringRef, bool)’ ProfileDependence.cpp:68:73: note: candidate is: