similar to: [LLVMdev] Mutating the elements of a ConstantArray

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

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,

Hi all. Is it allowed to modify ConstantArray object within setOperand method, or it is better to leave old ConstantArray object and create new one? Thanks! -Stepan.

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

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

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

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.

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 should migrate to passing in a "Constant > *const* / unsigned" pair.

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

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

I talked about this with Nick in person months ago, and my understanding is that GlobalOpt is also an enabling optimization that needs to run early. For example, if we can eliminate an initializer to an internal global with no other stores to it, we can propagate the result. Maybe we should run it twice. On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola < rafael.espindola at gmail.com>

On Thu, May 1, 2014 at 11:12 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote: >> I talked about this with Nick in person months ago, and my understanding is >> that GlobalOpt is also an enabling optimization that needs to run early. >> For example, if we can eliminate an initializer to an

> On 2014-Jul-30, at 18:05, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2014-Jul-30, at 17:19, Reid Kleckner <rnk at google.com> wrote: >> >>> On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> Looking a little deeper, it's not "old-style" exactly; rejecting this

Heyho, Recently I tried out the ORCv2 JIT, especially the LLJIT. I gotta say, that I really like the new interface and the way you use it! However there is one thing I'm missing. I wrote a small bit code file, which should force having a global constructor. int wuff(); __declspec(noinline) int miau() { printf("Huhuhu"); return wuff(); } const int x = miau(); When I

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:

> On 2014-Jul-31, at 10:07, Reid Kleckner <rnk at google.com> wrote: > >> On Thu, Jul 31, 2014 at 9:49 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> Hold on, I'm still not sure what kind of guarantees (restrictions) the C >> API imposes. >> >> If I implement (2), then -verify will fail if someone (e.g.) adds >>

Hello there I'm trying to compile llvm-gcc, but the compilation fails. This is due to the fact that the ConstantArray class does no longer have the getAsString method. It has been actually removed on Jan 31 (commit 6a89228faca4b30c4abc29b5dec98bdac011ea4c). Is there a patch for llvm-gcc which overcomes this problem? I've just svn-updated my working copy but it didn't change

On Mon, Sep 2, 2013 at 5:18 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Reid, > > On 26/08/13 23:43, Reid Kleckner wrote: > >> To implement http://llvm.org/PR16959 >> <http://llvm.org/bugs/show_**bug.cgi?id=16959<http://llvm.org/bugs/show_bug.cgi?id=16959>>, >> I need to add a new field to >> >> global_ctors. >> >>

Hi Reid, On 03/09/13 20:08, Reid Kleckner wrote: > On Mon, Sep 2, 2013 at 5:18 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Reid, > > On 26/08/13 23:43, Reid Kleckner wrote: > > To implement http://llvm.org/PR16959 > <http://llvm.org/bugs/show___bug.cgi?id=16959 >

Hello, I'm working on porting a project to LLVM 3.1. Unfortunately, my project makes very heavy use of ContantArray::getAsString() -- which was removed in LLVM 3.1. Is there an equivalent in 3.1? In other words, what is the best way to get the value of a string that was stored in a ConstantArray? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed...