similar to: [LLVMdev] Combining LinkOnce and External

On Jun 9, 2008, at 7:13 PM, Talin wrote: > Before I go writing a bug report, I want to know if the behavior I am > seeing is intended. > > Before 1.3, I was able to generate a linkonce definition in one > module, > and an external declaration in another module and link them together, > with the result being a defined symbol with external linkage. However, > with the

http://llvm.org/docs/LangRef.html#linkage-types says: Globals with “linkonce” linkage are merged with other globals of the same name when linkage occurs. This can be used to implement some forms of inline functions, templates, or other code which must be generated in each translation unit that uses it, but where the body may be overridden with a more definitive definition later. Unreferenced

On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote: > Unreferenced linkonce globals are allowed to be discarded. > > > Is __udivmodti4 referenced? > It's referenced by a different .o file, but nothing within the module. My confusion comes from the missing direct object in the sentence. Referenced by a function local to the module? Referenced by any

As mentioned in the Updated ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am sending the symbol linkage and renaming required by ThinLTO as a separate RFC. It is included below. I've also attached the doc in pdf form, since the formatting (especially for the table at the end) may not come through in the copied text below well. Thanks! Teresa ThinLTO

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

Hi Duncan- Forgive my confusion, but I can't help notice that LangRef states: Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be discarded. Why

Hello, looking at Printer::doFinalization, I have some question about support of the different linkages. Here's a table of how that method handles the possible combinations: Initialized Null Internal .data, local .data, .comm, .local External .data, .globl .bss, .globl,

Hi Alastair, > Forgive my confusion, but I can't help notice that LangRef states: > > Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be

Dustin Laurence wrote: > On 01/08/2010 02:10 PM, John McCall wrote: > > >> 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat >> machine-code and object-file optimizations, but it does not apply >> high-level optimizations like CSE or inlining. 'opt' is the tool >> which does IR-to-IR optimization. >> > > A

On 01/08/2010 02:10 PM, John McCall wrote: > 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat > machine-code and object-file optimizations, but it does not apply > high-level optimizations like CSE or inlining. 'opt' is the tool > which does IR-to-IR optimization. A vital clue, but I'm still not getting it: --- gemini:~/Projects/Nil/nil(0)$

Hi Nick, Bigcheese, I wanted to add support to support .gnu.linkonce sections in the resolver. _*About .gnu.linkonce sections*_ .gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations. We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in

... > Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a similar > patch. > > cool!, I will make that change and submit it too. > ... > Yes probably, I don't know what the .def and .scl directives "do" :) > > I think I can figure out the right thing to do here. > Also, w.r.t. section handling stuff, there is this fixme in the asmprinter:

Hi Dustin, > define linkonce fastcc i32 @foo(i32 %arg) alwaysinline linkonce implies that the function body may change at link time. Thus it would be wrong to inline it, since the code being inlined would not be the final code. Use linkonce_odr to tell the compiler that the function body can be replaced only by an equivalent function body. Ciao, Duncan.

OK, I wanted to understand function inlining in LLVM but had avoided going to the effort of finding out if the inlining was really happening. The advice I got to "use the assembly source, Luke" suggested I go ahead and investigate inlining for a bit of practice, since (so I figured) even a monkey with really weak x86-fu could tell whether a function call was happening or not. If this

I'm getting an error in the verifier after running a custom pass: Alias should have external or external weak linkage! This constraint isn't mentioned in the LangRef. According to the verifier code, the only permitted linkage types for a GlobalAlias are external, internal and weak. Why is that? The LangRef describes weak in terms of common, and common in terms of linkonce. Is

----- 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

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

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

Hi, Currently if the linker encounters a pair of linkonce function definitions with different types, it raises an error of the form: llvm-ld: error: Cannot link file 'item.o.bc': Function '_ZN18st_select_lex_unit12first_selectEv' defined as both ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)' and ' %struct.SELECT_LEX* (%struct.SELECT_LEX_UNIT*)'

I'm working with a C++ code generator that produces multiple instances of the same definition (specifically, it generates explicit instantiations of the same template in multiple output source files). With the GNU ld, I'm able to link successfully using the --allow-multiple-definitions flag; however this flag is not supported in llvm-ld. Is there any way I can either convince llvm-ld to