search for: isweakforlinker

...90..ee11d07d6b8e 100644 --- a/llvm/lib/LTO/LTO.cpp +++ b/llvm/lib/LTO/LTO.cpp @@ -287,7 +287,7 @@ static void thinLTOResolveWeakForLinkerGUID( recordNewLinkage) { for (auto &S : GVSummaryList) { GlobalValue::LinkageTypes OriginalLinkage = S->linkage(); - if (!GlobalValue::isWeakForLinker(OriginalLinkage)) + if (GlobalValue::isLocalLinkage(OriginalLinkage)) continue; // We need to emit only one of these. The prevailing module will keep it, // but turned into a weak, while the others will drop it when possible. diff --git a/llvm/lib/Transforms/IPO/FunctionImport.c...

...emantics. For example, on ELF if a symbol is defined in a COMDAT in one object file, it must be defined in every object file that has that COMDAT. Given that weak symbols get implemented with COMDATs, the actual rule at the llvm level would have to be something like * If an alias is declared to a isWeakForLinker symbol in one object file, it must be defined in all. This is very restrictive rule. For example, given struct A { virtual ~A() {} }; struct B : public A { virtual ~B() {} }; It is nice for clang to be able to say "I know @_ZN1BD2Ev and @_ZN1AD2Ev" are the same", but there is...

...llvm/lib/LTO/LTO.cpp > +++ b/llvm/lib/LTO/LTO.cpp > @@ -287,7 +287,7 @@ static void thinLTOResolveWeakForLinkerGUID( > recordNewLinkage) { > for (auto &S : GVSummaryList) { > GlobalValue::LinkageTypes OriginalLinkage = S->linkage(); > - if (!GlobalValue::isWeakForLinker(OriginalLinkage)) > + if (GlobalValue::isLocalLinkage(OriginalLinkage)) > continue; > // We need to emit only one of these. The prevailing module will keep > it, > // but turned into a weak, while the others will drop it when > possible. > diff --git a/llvm/...

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

...allee was linkonce_odr, and so the function body that I was instrumenting was not making its way into the final executable. This is why I was not seeing my debug info printed. So if I am looking at a CallInst, and want to know if the callee is going to be instrumented by my pass, I can check F->isWeakForLinker(), where F is the called function. But this just tells me when the function definition *may* be replaced. I want to know precisely when the CallInst is a call to a function that I am going to instrument as part of my pass (ignore indirect invocations for the moment). Obviously I could do an initial...

...ght thing. For example, to determine whether to emit $non_lazy_ptr, it uses a logic tree like this: if (shouldPrintStub(TM, Subtarget)) { // Link-once, declaration, or Weakly-linked global variables need // non-lazily-resolved stubs if (GV->isDeclaration() || GV->isWeakForLinker()) { // Dynamically-resolved functions need a stub for the function. if (GV->hasHiddenVisibility()) { if (!GV->isDeclaration() && !GV->hasCommonLinkage()) ... else { printSuffixedName(Name, "$non_lazy_ptr");...

On Mar 16, 2010, at 6:46 PM, Scott Ricketts wrote: > I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: > > 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) The "tail" marker has a very specific description in LLVM IR: it says that the caller does not access the

Hi Scott, > So if I am looking at a CallInst, and want to know if the callee is > going to be instrumented by my pass, I can check F->isWeakForLinker(), > where F is the called function. But this just tells me when the > function definition *may* be replaced. I want to know precisely when > the CallInst is a call to a function that I am going to instrument as > part of my pass (ignore indirect invocations for the moment). > Obviou...

I have some code generated with llvm-g++ and llvm-link that includes a tail call that is confusing me for two reasons: 1) I am not sure why it is a tail call (i.e. it does not look like it is in the tail position) 2) When I instrument the code using my opt pass, none of the instrumentation functions in the callee get called, leading me to believe that some funny business is going on. Below I

...{ + + EVT PtrVT = getPointerTy(); + SDLoc dl(Op); + const GlobalAddressSDNode *GN = cast<GlobalAddressSDNode>(Op); + const GlobalValue *GV = GN->getGlobal(); + unsigned Alignment = GV->getAlignment(); + Reloc::Model RelocM = getTargetMachine().getRelocationModel(); + if (GV->isWeakForLinker() && GV->isDeclaration() && RelocM == Reloc::Static) { + // Weak undefined symbols can't use ADRP/ADD pair since they should evaluate + // to zero when they remain undefined. In PIC mode the GOT can take care of + // this, but in absolute mode we use a constant pool...