similar to: [LLVMdev] Rolling my own appending linkage

On Tue, Jan 25, 2011 at 9:14 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote: > > > Hi Talin, > > > >> Really, all I need to make this work is some way to 'mark' a global so > that my > >> custom pass can query for all marked globals. Any ideas on this? > > > > metadata maybe?

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

On Jan 24, 2011, at 11:57 PM, Duncan Sands wrote: > Hi Talin, > >> Really, all I need to make this work is some way to 'mark' a global so that my >> custom pass can query for all marked globals. Any ideas on this? > > metadata maybe? A better approach would be to create an global array of strings to hold names of marked globals. You know the name of this special

Hi Talin, > Really, all I need to make this work is some way to 'mark' a global so that my > custom pass can query for all marked globals. Any ideas on this? metadata maybe? Ciao, Duncan.

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

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

My apologies for opening up an old thread, but I've been thinking about this quite a bit lately, and it seems to me that "appending linkage" would be a lot more useful in general if there was some way to determine the size of the appended array without having to write a custom pass to do it. In other words, using the standard llvm tools (llvm-link and friends), one ought to be

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

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

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 >

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

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

So, I was in the process of writing a custom LLVM pass (my first one, yay!) to handle the problem of measuring the length of an appending linkage array. The approach I was taking was pretty simple: Iterate through all of the module's global variables until I find one that is trying to calculate the end of an appending-linkage array, which looks like this: @_moduleListEnd = constant [1 x

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

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

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've been using LLVM for quite a few months now, as part of writing a compiler for a statically typed programming language. During this time, I've been keeping a list of improvements I would like to see in LLVM. Note that most of the items on this list are issues that I have posted here before. I thought it might be a useful bit of feedback to summarize just the most important, most

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

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

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