search for: newgv

...y of GlobalVariable without copying attributes from the original one. Consider this one: http://llvm.org/doxygen/GlobalOpt_8cpp_source.html static bool TryToShrinkGlobalToBoolean(GlobalVariable *GV, Constant *OtherVal) { ... // Create the new global, initializing it to false. GlobalVariable *NewGV = new GlobalVariable(Type::getInt1Ty(GV->getContext()), false, GlobalValue::InternalLinkage, ConstantInt::getFalse(GV->getContext()),...

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

...Sergei Larin > Cc: llvm-dev at lists.llvm.org; Lang Hames > Subject: Re: GlobalOPT and sections > > On Sep 18, 2015, at 10:45 AM, Sergei Larin <slarin at codeaurora.org> wrote: > > What I do not see - the section information from the original GV is never > copied to the NewGV, so this test would be failing for me: > > Now the proverbial question - is this a bug or a feature? ...and if it was > meant to be done that way then why… > > Historically speaking, this optimization probably predated the ability to put a > section on a global. > > That...

...o 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 index ) > { > return &array[index]; > }...

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

...tch is attached. Your patch 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

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 this. Why didn't I see that there? I must be bli...

> 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

...ion Attrs: nounwind uwtable declare void @foo(%"type1"*) unnamed_addr #2 align 2 Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize. BTW, I updated LLVM to the latest version in SVN this morning, and the assertion failure is gone. I...

...eclare void @foo(%"type1"*) unnamed_addr #2 align 2 > > > > Inside IRLinker::linkGlobalValueProto, the materialized value is returned > from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is > true and ShouldLink is false, DGV becomes nullptr later, and NewGV is > created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, > returned value from linkGlobalValueProto is different from the value > obtained by ValueMap.lookup(SGV) in IRLinker::materialize. > Ah, sorry, somehow I completely missed the fact that it was brought in as a dec...

...Attrs: nounwind uwtable declare void @foo(%"type1"*) unnamed_addr #2 align 2 Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize. Ah, sorry, somehow I completely missed the fact that it was brought in as a decl when I looked this...

...eclare void @foo(%"type1"*) unnamed_addr #2 align 2 > > > > Inside IRLinker::linkGlobalValueProto, the materialized value is returned > from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is > true and ShouldLink is false, DGV becomes nullptr later, and NewGV is > created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, > returned value from linkGlobalValueProto is different from the value > obtained by ValueMap.lookup(SGV) in IRLinker::materialize. > > > > Ah, sorry, somehow I completely missed the fact that it was broug...

...Attrs: nounwind uwtable declare void @foo(%"type1"*) unnamed_addr #2 align 2 Inside IRLinker::linkGlobalValueProto, the materialized value is returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, returned value from linkGlobalValueProto is different from the value obtained by ValueMap.lookup(SGV) in IRLinker::materialize. Ah, sorry, somehow I completely missed the fact that it was brought in as a decl when I looked this...

...s? I would feel > better if 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/us...

...eclare void @foo(%"type1"*) unnamed_addr #2 align 2 > > > > Inside IRLinker::linkGlobalValueProto, the materialized value is returned > from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is > true and ShouldLink is false, DGV becomes nullptr later, and NewGV is > created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, > returned value from linkGlobalValueProto is different from the value > obtained by ValueMap.lookup(SGV) in IRLinker::materialize. > > > > Ah, sorry, somehow I completely missed the fact that it was broug...

...>>> >>> >>> >>> Inside IRLinker::linkGlobalValueProto, the materialized value is >>> returned from getLinkedToGlobal(SGV) and assigned to DGV. However, as >>> ForAlias is true and ShouldLink is false, DGV becomes nullptr later, and >>> NewGV is created from copyGlobalValueProto(SGV, ShouldLink) call. >>> Therefore, returned value from linkGlobalValueProto is different from the >>> value obtained by ValueMap.lookup(SGV) in IRLinker::materialize. >>> >>> >>> >>> Ah, sorry, somehow I c...

...eclare void @foo(%"type1"*) unnamed_addr #2 align 2 > > > > Inside IRLinker::linkGlobalValueProto, the materialized value is returned > from getLinkedToGlobal(SGV) and assigned to DGV. However, as ForAlias is > true and ShouldLink is false, DGV becomes nullptr later, and NewGV is > created from copyGlobalValueProto(SGV, ShouldLink) call. Therefore, > returned value from linkGlobalValueProto is different from the value > obtained by ValueMap.lookup(SGV) in IRLinker::materialize. > > > > Ah, sorry, somehow I completely missed the fact that it was broug...

On Thu, Jul 28, 2016 at 5:18 PM, Taewook Oh <twoh at fb.com> wrote: > Hello Teresa, > > > > Thank you for your reply. I’m trying to create a small repro but find it > hard to nail down because originally it is a big build. This happens with > gold linker. > I think I need to see a smaller test case, looking through the code I'm not sure how we ended up in this

Hello Teresa, Thank you for your reply. I’m trying to create a small repro but find it hard to nail down because originally it is a big build. This happens with gold linker. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Thursday, July 28, 2016 at 5:08 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev]