similar to: [RFC] Fail early on unimplementable append linkage uses

On 13 May 2016 at 08:51, Renato Golin <renato.golin at linaro.org> wrote: > On 13 May 2016 at 13:43, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: >> That means that appending linkage can only be used with llvm special >> symbols that never hit a real .o. > > So they should have been resolved by emission time, or it's a back-end error. Not resolved,

Sorry if this question is a repeat, I never got an answer the last time I asked :) How does appending linkage interact with dead global elimination? From what I understand, appending linkage arrays are stitched together by the linker. Dead global elimination usually happens after linking, so if any of those arrays are "live", then any globals that they point to will be live as well. My

On Thu, Dec 10, 2009 at 12:26 AM, Robin Sommer <robinsommer at web.de> wrote: > > On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: > >> the LLVM documentation lists the 'appending' linkage for having the >> linker combine two arrays. I'm wondering though if it's then >> possible to get the size of the combined array, e.g., for iterating >> over

Hello. I'm posting this question here, because there seem to be no LLD-specific mailing list. Sorry in advance if this is wrong one. I compile two C source with following command: clang -flto -o %name.bc %name.c LLVM is augmented with my custom pass, which amongst other things create a global with appending linkage: @myvar = appending constant [1 x [1 x i8]*] ... I also have another pass

On Thu, Dec 10, 2009 at 2:05 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 10, 2009 at 12:26 AM, Robin Sommer <robinsommer at web.de> wrote: >> >> On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: >> >>> the LLVM documentation lists the 'appending' linkage for having the >>> linker combine two arrays. I'm wondering

This is an issue I raised a while ago, but I wanted to know if the situation had improved at all recently. The issue is determining the number of elements in an array that has appending linkage. The obvious course would be to use a constant GEP. Suppose we have N modules, each containing a global variable with appending linkage whose initializer is an array of size M containing elements of type

I'm trying to figure out how to do static initialization (like static constructors in C++ or Java). I figured I would use appending linkage - that is, for each module I'd generate a function that did all of the static initialization for that module, and then I'd put a pointer to that function in an array with appending linkage. Then my compiler-generated startup code would simply

Hi all, the LLVM documentation lists the 'appending' linkage for having the linker combine two arrays. I'm wondering though if it's then possible to get the size of the combined array, e.g., for iterating over its elements? Or how would I otherwise use the combined array? Thanks, Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1

Talin wrote: > I'm trying to figure out how to do static initialization (like static > constructors in C++ or Java). I figured I would use appending linkage - > that is, for each module I'd generate a function that did all of the > static initialization for that module, and then I'd put a pointer to > that function in an array with appending linkage. Then my >

On Tue, Feb 18, 2020 at 9:42 PM David Blaikie <dblaikie at gmail.com> wrote: > I'm /guessing/ this might be related to the COFF support specifically > (perhaps COFF has no appending linkage support - in some cases LLVM IR > supports the union of all semantics so that different formats can be fully > expressed - but it means when targeting certain formats, some features are

On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: > the LLVM documentation lists the 'appending' linkage for having the > linker combine two arrays. I'm wondering though if it's then > possible to get the size of the combined array, e.g., for iterating > over its elements? Or how would I otherwise use the combined array? Any thoughts on this? Am I missing something?

I think I finally understand how appending linkage type works and what it can be used for. What isn't obvious to me is how one gets the size of the resulting array. I'm thinking about using this to store bits of source language information and understand that it gets concatenated together by the linker. At both compile time and runtime, I want to be able to load an arbitrary bytecode

John Criswell wrote: > Talin wrote: > >> I'm trying to figure out how to do static initialization (like static >> constructors in C++ or Java). I figured I would use appending linkage - >> that is, for each module I'd generate a function that did all of the >> static initialization for that module, and then I'd put a pointer to >> that function in

Can anyone explain how llc translates "appending linkage" global variables like llvm.global_ctors into assembly? In the case I am examining, the global_ctor variables are in multiple bitcode object modules produced by the llvm compiler as arrays of pointers. As documented, the arrays seem to be combined when the different bitcode object modules are linked into one, so now there is one

> That's essentially what I did to get it to work but instead of > appending, I just opted for LinkOnce. Sounds ok. > > I don't quite understand why you need an appending global to do this, if you > > can only have one main. I would just set it to the correct initializer in the > > module that has main, and leave it external everywhere else. > > Its

The problem I'm experiencing with Stacker has to do with linkage types (again!). What I'm trying to do is create a "global appending" array. In compilation units that don't include "main", I generate it with: TheStack = new GlobalVariable( /*type=*/ stack_type, /*isConstant=*/ false, /*Linkage=*/

Hi, The LLVM language reference doesn't say that extern_weak is illegal for function definitions, but it seems this restriction is enforced in the code in some places: https://github.com/llvm-mirror/llvm/blob/master/lib/AsmParser/LLParser.cpp#L4591 https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#L327 However it is possible to create a bitcode file

On Jan 30, 2011, at 8:36 PM, Talin wrote: > So, I spent the better part of a day making sure that each and every static global had a well-formed and unique name. So far so good. > > However, It turns out that what I need is a little different than what I described - I not only need to know which globals should be traced, but I also need to associate with each of these globals a data

+nick and rafael, who seem to a lot about linkage. I made the following claim on llmv-commits [1]: On 2014 Mar 3, at 15:01, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > Giving these functions internal linkage allows them to be dead-stripped. Is that even correct? This is the assumption I’ve been working under, but I’m not sure where I got it from. It seems like 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