similar to: [LLVMdev] LLVM features that ought to be surfaced in a higher-level language?

I needed this functionality to solve http://llvm.org/PR20653, but it obviously has far more general applications. You can do it like this: define i32 @my_forwarding_thunk(i32 %arg1, i8* %arg2, ...) { ... ; define new_arg1 and new_arg2 %r = musttail call i32 (i32, i8*, ...)* @the_true_target(i32 %new_arg1, i8* %new_arg2, ...) ret i32 %r } declare i32 @the_true_target(i32, i8*, ...) The

On Sun, Jul 3, 2011 at 9:07 AM, Chris Lattner <clattner at apple.com> wrote: > Hi Talin, > > Interesting post, > > On Jul 1, 2011, at 11:05 AM, Talin wrote: > > *Garbage collection is still way too difficult*. The biggest problem is > the inability to track SSA values - it requires the > > > *Light-weight coroutines* would be a "nice to have", as

On 8 Oct 2014, at 18:19, Reid Kleckner <rnk at google.com> wrote: > The one target I know about where varargs are passed differently from normal arguments is aarch64-apple-ios/macosx. After thinking a bit more, I think this forwarding thunk representation works fine even on that target. Typically a forwarding thunk is called indirectly, or at least through a bitcast, so the LLVM IR call

BLAST! LLVM mailing list headers are still royally screwed up... My message is below... On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote: > Hey all, it's been a while since I have posted on this list, but I've > been continuing my work with LLVM and getting lots done :) > > One question I wanted to ask is whether anyone had any advice on how to >

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at

Hi Talin, Interesting post, On Jul 1, 2011, at 11:05 AM, Talin wrote: > Garbage collection is still way too difficult. The biggest problem is the inability to track SSA values - it requires the > Light-weight coroutines would be a "nice to have", as would better concurrency primitives. These are things I could Tackling the "still way too difficult" and "should

Here's my latest version of Hashing.h, which I propose to add to llvm/ADT. Comments welcome and encouraged. On Thu, Feb 9, 2012 at 11:23 AM, Talin <viridia at gmail.com> wrote: > By the way, the reason I'm bringing this up is that a number of folks are > currently working on optimizing the use of hash tables within LLVM's code > base, and unless we can come up with a

On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > You are not doing something wrong, it is just that the LLVM optimizers > consider llvm.gcroot like a regular function call. The alloca is moved in > the first block most probably because the inliner anticipates another > optimization pass (the mem2reg). > OK, well,

So, based on the info that I got from Devang, I was able to solve the problem with the duplicate assembly symbols, although I still don't quite understand why it was generating erroneous metadata in the first place. For example, through trial and error I discovered that the problem disappeared if I passed my DICompileUnit to CreateLocation() rather than my DISubprogram, but I don't know

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > >> I think I'm one of the few people actually using LLVM's support for >> garbage collection, and so far I've found it very difficult to generate code >> that uses llvm.gcroot() correctly. >> >> In

On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > > On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > >> I recently started getting this error when I try to debug my LLVM-compiled >> program in GDB: >> >> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c >> [in module

On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > Sorry, I meant DIBuilder. DIBuilder is the new DIFactory. I've been playing with it this week and it's much easier and straightforward to use. I'm still having problems to create arrays, though. As far as I remember (from the 2010 meeting), the idea was to replace and deprecate DIFactory. I'm not saying we

On Sat, Jul 23, 2011 at 5:09 PM, Talin <viridia at gmail.com> wrote: > So this was working fine for me until a few days ago when I checked out the > most recent LLVM - the one with the new type system. Now I am getting the > same error that I was getting previously. > Is it possible that your fix got unfixed when they merged in the new branch? I wouldn't be surprised if

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

I'd like to figure out a clean way to annotate LLVM types with additional information. This is related to the garbage collection discussion - I'd like to figure out a good way to do this, so I can add it to the proposal. Basically what I want is to be able to take a Constant and associate it with a type, such that (1) any backend pass that has a reference to the type can quickly and

I've written a little GUI application that displays an LLVM module as an expandable tree, which can be useful for examining the module's contents. Some features: - Based on wxWidgets, so it's completely cross-platform. - CMake build script can locate both LLVM and wxWidgets installations automatically. - Loads either .ll or .bc files. - Supports browsing of LLVM types,

I didn't have unions in mind - indeed you need some kind of static information in such a case. The GC infrastructure in LLVM having so little love, I think it is good if you can improve it in any ways, as well as defining new interfaces. Cheers, Nicolas On Sat, Sep 25, 2010 at 6:38 PM, Talin <viridia at gmail.com> wrote: > On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray < >