similar to: [LLVMdev] RFC: ThinLTO Symbol Linkage and Renaming

An enumeration for the kinds of linkage for global values. Hi, I'm currently writing a compiler that takes llvm-ir input. I'm a little confused by the following linkage flags: Enumerator: > > ExternalLinkage: Externally visible function > > AvailableExternallyLinkage: Available for inspection, not emission. > > LinkOnceAnyLinkage: Keep one copy of function when linking

Thanks for the comments! Responses below. Teresa On Tue, Jul 21, 2015 at 1:06 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jul-14, at 13:33, Teresa Johnson <tejohnson at google.com> wrote: > > > > As mentioned in the Updated ThinLTO RFC ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am > sending the

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Reid Kleckner" <rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage

> > This scares me a little for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module

What is the difference between WeakAnyLinkage and ExternalWeakLinkage ? They are defined in GlobalValue.h. Thanks Junjie

There is a description of all the possible linkage types at http://llvm.org/docs/LangRef.html#linkage – does this answer your question? (Basically, an extern_weak resp. ExternalWeakLinkage symbol becomes null instead of being an undefined reference) David On 3/16/11 7:06 PM, Junjie Gu wrote: > What is the difference between WeakAnyLinkage and ExternalWeakLinkage > ? They are defined

Hi all, Below is a proposal for refining the way we communicate between the ThinLTO link step (the combined indexing step) and the backend processes that do the actual importing and other summary-based optimizations in a distributed backend process. Mehdi, let me know if this addresses your concerns. Peter, PTAL from the standpoint of any summary extensions needed for CFI and make sure they can

On Wed, Jun 7, 2017 at 8:58 AM, Charles Saternos <charles.saternos at gmail.com > wrote: > Alright, now it outputs YAML in the following format: > > --- > NamedGlobalValueMap: > X: > - Kind: GlobalVar > Linkage: ExternalLinkage > NotEligibleToImport: false > Live: false > a: > - Kind:

Great! For the hotness, try creating a small test case with a very hot loop that iterates many times. Let me know if you are still having trouble. While the llvm-dis serialization is being discussed, I suppose at the very least this can go in with the rest of the existing YAML summary dumping and get emitted from llvm-lto2 using the patch Peter attached. Peter - do you want to add that to

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

On Fri, May 15, 2015 at 9:18 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> - Marking of imported functions (for use in ThinLTO-specific symbol >> >> linking and global DCE, for example). >> > >> > Marking how? Do you mean giving them internal linkage, or something >> > else? >> >> Mentioned just after this: either

I think that all makes sense. You're just adding the missing non-ODR conterpart of 'external' linkage. I could imagine having "external / external_odr" linkage for example. That said, do you think we should take the opportunity to split out a bit for interposability so that we can kill off the *_odr linkage variants? Today's non-ODR weak functions would look more like

On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 15, 2015 at 9:20 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > On Fri, May 15, 2015 at 9:18 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >>> > >>> > >>> >> - Marking of imported functions (for use

2017-06-06 13:38 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-05 14:27 GMT-07:00 David Blaikie via llvm-dev < >> llvm-dev at lists.llvm.org>: >> >>> I know there's been a bunch of discussion here already, but I was >>> wondering if

That is a good question and I don't know. The optimization is defined include/llvm/Analysis/ObjectUtils.h. If I enable that for weak_odr + unnamed_addr, no tests are failing so I guess it is a safe optimization? :) It is probably because the autohide optimization is targeted at c++ templates and inline functions and we know they have linkonce_odr linkage, which suggests whoever uses this

>From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. Realistically, nobody cares

Okay, I'm past the GEP "have to dereference pointer first" problem of my last post. I now have a linkage error (I get undefined symbol when I try to assemble the program). gcc -o test.o test.s says: > /tmp/cczhiFk7.o(.text+0x7): In function `a': > : undefined reference to `_index_' _index_ is defined like this: > %_index_ = external global long ;

> From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. I think there is a nuance, it

On Wed, Feb 7, 2018 at 11:35 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > From looking at the code, it seems like LLVM is basically opting MachO > into -fvisibility-inlines-hidden all the time, i.e. if the function is > linkonce, it's discardable, so mark it hidden to pretend the compiler > inlined it and discarded it. However, this isn't conforming, because