search for: linkonceodr

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit != &StaticStuff&l...

...> On Mon, Jan 12, 2015 at 11:45 AM, Axel Naumann <Axel.Naumann at cern.ch > <mailto:Axel.Naumann at cern.ch>> wrote: > > Hi, > > I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I > only ran into this issue: > > $ cat linkonceodr.cxx > extern "C" int printf(const char*,...); > > template <class T> struct StaticStuff { > static T s_data; > }; > template <class T> T StaticStuff<T>::s_data = 42; > > int compareAddr(int* mcjit); > > #ifde...

...del off. > OptRemarks: [IRSim][IROutliner] Adding OptRemarks for the IROutliner. > Function Attribute Merging: [IRSim][IROutliner] Adding consistent function attribute merging > DebugInfo Handling: [IRSim][IROutliner] Adding DebugInfo handling for IR outlined functions. > Outlining from linkonceodr: [IRSim][IROutliner] Adding option to enable outlining from linkonceodr functions > Flexibility for Isomorphic Predicates: [IRSim] Adding support for isomorphic predicates > Flexibility for Commutative Instructions: [IRSim] Adding commutativity matching to structure checking > Matching cal...

Indeed, an awesome project and an excellent report! Code size doesn't really get much attention, so the level of detail and the strong roadmap is refreshing. Hopefully, the project will provide execution times along with code-size > reductions. > I doubt it. Outlining will (almost?) always make for slower code due to a lot more calls being made. But that's ok for embedded targets,

...ode as weak. > > > Some more prior discussion: https://reviews.llvm.org/D19995#423481 > > +1 So we're all on the same page, our current encodings are: External: 0 WeakAny: 16 Appending: 2 Internal: 3 LinkOnceAny: 18 ExternalWeak: 7 Common: 8 Private: 9 WeakODR: 17 LinkOnceODR: 19 AvailableExternally: 12 And the new encodings would be: External: 0 External + Interposible: 20 Weak + Interposible: 16 Appending: 2 [interposible N/A] Internal: 3 [never interposible] LinkOnce + Interposible: 18 ExternalWeak: 7 [always interposible] Common: 8 [interposible N/A] Pr...

...IRSim][IROutliner] Adding OptRemarks for the IROutliner. > >> Function Attribute Merging: [IRSim][IROutliner] Adding consistent function attribute merging > >> DebugInfo Handling: [IRSim][IROutliner] Adding DebugInfo handling for IR outlined functions. > >> Outlining from linkonceodr: [IRSim][IROutliner] Adding option to enable outlining from linkonceodr functions > >> Flexibility for Isomorphic Predicates: [IRSim] Adding support for isomorphic predicates > >> Flexibility for Commutative Instructions: [IRSim] Adding commutativity matching to structure checking...

...gt; We don’t import the IR so the destination module is OK. > Presumably we have decided to import globalfunc1 (otherwise renameModuleForThinLTO would not convert its linkage type), but not weakalias (since selectcallee should block it because aliases can't be imported unless the aliasee is linkonceodr). And the dest module is ok because we only import globalfunc1 and not weakalias. In that case, yes, I guess the source module can't be verified after doing renameModuleForThinLTO. Why not just verify before we do renameModuleForThinLTO, and then the dest module again after IR linking? Not sure...

...t; +----------------------------------------------------------------------------------+ > > | LinkOnceAny (def) | LinkOnceAny | N/A (force > import def) | > > > +----------------------------------------------------------------------------------+ > > | LinkOnceODR (def) | LinkOnceODR | N/A (force > import def) | > > > +----------------------------------------------------------------------------------+ > > | WeakAny (def) | N/A (never import) | > ExternalWeak | > > > +--------...

...structors and destructors lists. We never import these as they would get executed multiple times, which is incorrect. 2.2.4 CommonLinkage Since common symbols are always zero-initialized variables, they do not take up room. It is simplest to import these defs as common. 3 Linkonce Values The LinkOnceODRLinkage and LinkOnceAnyLinkage types refer to linkonce linkage, which allows merging of different globals with the same name. Unreferenced linkonce globals may also be discarded. Linkonce values include some COMDAT functions (COMDAT may also have Weak linkage) and vtable variables. For linkonce valu...

...t;> Three patches are attached, for llvm, clang, and compiler-rt respectively. >> >> TODO: >> (1) Migrate to the new pass manager with a shim for the legacy pass >> manager. >> (2) For the order file buffer, consider always emitting definitions, >> making them LinkOnceODR with a COMDAT group. >> (3) Add testing case for clang/compiler-rt patches. >> (4) Add utilities to deobfuscate the profile dump. >> (5) The size of the buffer is currently hard-coded ( >> INSTR_ORDER_FILE_BUFFER_SIZE). >> >> Thanks Kamal for contributing to the...

...39; which inserts a function call and is not as efficient. Three patches are attached, for llvm, clang, and compiler-rt respectively. TODO: (1) Migrate to the new pass manager with a shim for the legacy pass manager. (2) For the order file buffer, consider always emitting definitions, making them LinkOnceODR with a COMDAT group. (3) Add testing case for clang/compiler-rt patches. (4) Add utilities to deobfuscate the profile dump. (5) The size of the buffer is currently hard-coded ( INSTR_ORDER_FILE_BUFFER_SIZE). Thanks Kamal for contributing to the patches! Thanks to Aditya and Saleem for doing an ini...

...> > For WeakODRLinkage, there is a guarantee that all copies will be > equivalent, so the issue described above for WeakAny does not exist, and > the definition can be imported. For WeakODRLinkage, the imported definition > should retain the original WeakODRLinkage. > > I think LinkOnceODRLinkage has the right semantics here. > > > If imported as a declaration, it should instead have ExternalWeakLinkage. > > I think you can get away with just ExternalLinkage for this? We > found a definition to import, so it must exist somewhere. > > Moreover, thinking about...

...rt >>>> respectively. >>>> >>>> TODO: >>>> (1) Migrate to the new pass manager with a shim for the legacy pass >>>> manager. >>>> (2) For the order file buffer, consider always emitting definitions, >>>> making them LinkOnceODR with a COMDAT group. >>>> (3) Add testing case for clang/compiler-rt patches. >>>> (4) Add utilities to deobfuscate the profile dump. >>>> (5) The size of the buffer is currently hard-coded ( >>>> INSTR_ORDER_FILE_BUFFER_SIZE). >>>> >&g...

Assuming everyone is on the same page, here's a rough high level agenda: # step A: Introduce an `interposable` function attribute We can bike shed on the name and the exact specification, but the general idea is that you cannot do IPA / IPO over callsites calling `interposable` functions without inlining them. This attribute will (usually) have to be used on function bodies that can

...ROutliner Cost Model: Adds a cost model, so that reductions are prioritized rather than what comes first in terms of sheer code size outlined. IROutliner with OptRemarks: Adding OptRemarks to the outliner. IROutliner with SwiftError: Adding support for swifterror outlined parameters IROutliner with LinkOnceODR: Adding flag to outline from LinkOnceODR functions. Any feedback, comments, and discussion are welcome and appreciated! Thank You, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/8dd541a4/atta...

> On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hey, > > As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on

...gt; describing it because it seems deeply overlapping with linkage, which is > where the whole interposition thing comes from, and yet you never mention > how it interacts with linkage at all. What does it mean to have a common > linkage function that lacks the interposable attribute? Or a LinkOnceODR > function that does have that attribute? What would you say about adding this as a new kind of linkage? I was trying to avoid doing that since the intended semantics of, GlobalValue::InterposableLinkage don't just describe what a linker does, but also restricts what can be legally linked...

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