similar to: linkonce expected behavior?

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

On Thu, Apr 26, 2018 at 3:44 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Most probably you need to properly specify the calling convention the > backend is using for calling the runtime functions. Thanks for the tip. Can you be more specific? Are you suggesting there is some config parameter I can set before running TargetMachineEmitToFile? Do you know what

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

I'm trying to use LLVM to create compiler-rt.o on Windows. I use this command from the compiler-rt project: [nix-shell:~/downloads/llvm-project/compiler-rt]$ clang -nostdlib -S -emit-llvm lib/builtins/udivti3.c -g -target x86_64-windows -DCRT_HAS_128BIT The resulting LLVM IR is: ================================================================= ; ModuleID = 'lib/builtins/udivti3.c'

Most probably you need to properly specify the calling convention the backend is using for calling the runtime functions. Or implement the stub for udivti3 that performs the necessary argument lifting. I guess there is no standard ABI document describing the intended calling convention here, so I'd just do what mingw64 does here and make everything here compatible. On Thu, Apr 26, 2018 at

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

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

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 latest head, it apparently discards the linkonce version, and my output contains

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

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.

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

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

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

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

Here is some zig code: pub fn setXmm0(comptime T: type, value: T) void { comptime assert(builtin.arch == builtin.Arch.x86_64); const aligned_value: T align(16) = value; asm volatile ( \\movaps (%[ptr]), %%xmm0 : : [ptr] "r" (&aligned_value) : "xmm0" ); } I want to improve this and integrate more tightly with LLVM IR,

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, 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*)'

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

Hi Nick, I am trying to implement support for handling section groups in lld. There are two ways of figuring out section groups with ELF. a) Sections with SHF_GROUP property b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is

On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: > I am trying to implement support for handling section groups in lld. > > There are two ways of figuring out section groups with ELF. > > a) Sections with SHF_GROUP property > b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. > >