search for: oldgv

...ers for the array. When you need a reference to the array, use the global created by #1. 3. When you have the final array, create a *new* global with the correct size and the initializer formed from the vector. 4. Replace the old GV with the new GV using code that looks like this: OldGV->replaceAllUsesWith(ConstantExpr::getCast(NewGV, OldGV->getType()); OldGV->eraseFromParent(); At the end of this, any instructions or other globals that referenced the temporary global will now reference the new one. > int array[size] = { ... }; > > int* globalArray( int in...

I am trying to generate LLVM code that references a global array. Unfortunately, while I am generating the code I do not know the final length of the array, as I add elements to it as my compiler goes along. What is the best way to do this in LLVM? Ideally, I would be able to define the GlobalVariable array and change its length later on. I would love for it to have the correct length so I

> On Aug 26, 2016, at 2:06 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Mehdi: I see what is going on: > > + ArrayType *Ty = > + ArrayType::get(Type::getInt8Ty(RegularLTO.Ctx), I.second.Size); > + GlobalVariable *OldGV = RegularLTO.CombinedModule->getNamedGlobal(I.first); > + if (OldGV && OldGV->getType()->getElementType() == Ty) { > + // Don't create a new global if the type is already correct, just make > + // sure the alignment is correct. > > We compare the ex...

On Nov 2, 2005, at 16:39, Chris Lattner wrote: > 4. Replace the old GV with the new GV using code that looks like this: > > OldGV->replaceAllUsesWith(ConstantExpr::getCast(NewGV, > OldGV->getType()); > OldGV->eraseFromParent(); > > At the end of this, any instructions or other globals that referenced > the temporary global will now reference the new one. Ah ha! I was looking for something like th...

Thanks for the test case! I can reproduce this, and see with the compiler I saved from just before r278338 that this is indeed a chance in behavior. Looking at why this changed... On Fri, Aug 26, 2016 at 1:42 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Aug 26, 2016, at 1:34 PM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 12:47, Mehdi Amini wrote:

...preserves the current constructors. Is the idea that we wouldn't change the constructors, and clang would call setThreadLocalMode() when it creates global variables? I would feel better if we changed the constructors, to avoid the risk of forgetting to do stuff like NewGV->setThreadLocalMode(OldGV->getThreadLocalMode()) when new variables are created based on old ones. Thanks, Hans

> Attaching a new patch that has the behaviour we discussed. > > The "globaldynamic" and default values have been merged, and LLVM will > start off with the user-specified model, but choose a more specific > one if possible. > > Please review. Awesome, thanks! I will try to do a more complete review tonight or tomorrow. For now, just two quick observations *) This

> 1. How to find all constants in Module? Does this code find all of them, or > they are somewhere else too? > for (GlobalVariable &GV : globals()) { > if (auto C = static_cast<Constant*>(GV.Op<0>().get())) { > ... C is Constant* > } > } Constants are unfortunately part of the Context, not the module :-( Cheers, Rafael

...f we changed the constructors, to avoid the risk of forgetting > to do stuff like No, this was just a hack to get clang to build. I would suggest changing the constructor just like your patch does, but keeping the existing ones just forwarding to the new ones. > NewGV->setThreadLocalMode(OldGV->getThreadLocalMode()) when new > variables are created based on old ones. The rest of the review: + separated copy of the variable). Optionally, a suggested TLS model may be Not sure I would call it "suggested". What it is is a promise by the FE/user that some restrictions app...