search for: talin

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" exception (__cxa_pure_virtual) w...

Fine by me :) On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote: > > > Hi list, > > hi Talin, > > > > I'm working on a frontend to generate IR using the IRBuilder from > > LLVM. > > > > Now I want to add source-level-debuginfo and for that I would like > > to use the > > DebugInfoBuilder as it is taking some of the burderns. Unfortunately >...

...2) The ability for the size & alignment to be specified as Constants rather than as int64 so that the "gep trick" can be used to generate target-agnostic debug info. (I don't know if there are other aspects of the debug info which would prevent it from being target-agnostic.) -- Talin On Wed, Jan 7, 2009 at 1:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 7, 2009, at 1:48 PM, Talin wrote: > > Fine by me :) > > > Is it ok to remove DebugInfoBuilder now? I don't think that anything in > the tree is using it, what do you think Ta...

...0000000100101905 tart::Module::~Module() + 1609 14 tartc 0x00000001000fd67b __tcf_3 + 27 15 libSystem.B.dylib 0x00007fff830e6374 __cxa_finalize + 203 16 libSystem.B.dylib 0x00007fff830e628c exit + 18 17 tartc 0x000000010000173b start + 59 / On Sat, Oct 15, 2011 at 11:19 PM, Talin <viridia at gmail.com> wrote: > 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...

On Jan 7, 2009, at 1:48 PM, Talin wrote: > Fine by me :) Is it ok to remove DebugInfoBuilder now? I don't think that anything in the tree is using it, what do you think Talin? -Chris > > > On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> > wrote: > > On Jan 7, 2009, at 3:...

On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 8:11 AM, Talin wrote: > > >> If that's true, then it means that we're back to the case where every type >> has to be fully defined down to the leaf level. >> >> >> I'm not sure what you mean. LLVM is perfectly fine with opaque structs so >> long as you don...

DebugInfo.h is very light weight interface that allows one to manipulate llvm values that holds debugging information directly. On Jan 7, 2009, at 3:22 PM, Talin wrote: > Looking at DebugInfo.h, there are a couple of minor features that > DebugInfoBuilder that I would miss: > > 1) The ability to pass in an LLVM type and have it figure out the > size, alignment, etc. without having to explicitly pass those values > in as parameters t...

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, G...

...improving the code quality. > > Ciao, > > Duncan. > Interesting. After doing some more research, I noticed that Java uses a jsr to implement 'finally', at least according to this document: http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html -- Talin

On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Talin, > > > So, I just sync'd to LLVM tip and added the call to > DIBuilder::finalize(). But > > even with that change I am getting an error when I try to run llc: > > > > Assertion failed: (TheCU && "Unable to find compile unit!"), function > >...

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, is there...

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 < > nicolas.geoffray at gmail.com> wrote: > >> Hi Talin, >> >> On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote: >>> >>> >>>...

Yup. Now, the debug info nodes do not refer to compile unit. - Devang On Sep 5, 2011, at 2:23 AM, Duncan Sands wrote: > Hi Talin, I mentioned it because the error message you are getting is > identical (IIRC) to the error message being produced by llvm-gcc before > this patch went in. > > Ciao, Duncan. > > On 05/09/11 11:21, Talin wrote: >> On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <baldrick...

Hi Talin, I mentioned it because the error message you are getting is identical (IIRC) to the error message being produced by llvm-gcc before this patch went in. Ciao, Duncan. On 05/09/11 11:21, Talin wrote: > On Sun, Sep 4, 2011 at 11:38 PM, Duncan Sands <baldrick at free.fr > <mailto:baldric...

On Apr 7, 2011, at 12:14 PM, Talin wrote: > > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc:...

Hello, Talin > In any case, if someone wants to work on this feel free to use this > code, I've been too busy lately to make a patch. Please, file a PR - I'll take care about this. -- WBR, Anton Korobeynikov

...it in any ways, as well as > defining new interfaces. So the patch is OK then? All it does is change the verifier -- llvm.gcroot already has the ability to do this, its just that the verifier wouldn't allow it. > > 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 < >> nicolas.geoffray at gmail.com> wrote: >> >>> Hi Talin, >>> >>> On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com> wrote: >>&gt...

...is is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator, which is used by a StringMap, which is in turn a member of a statically initialized object.) Anyone know what might have changed recently that would cause this? -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111015/99821005/attachment.html>

Sure. I think we can change the GC lowering pass to recognize all llvm.gcroot (not only the ones in the first block), and move them to the first block so that they are initialized by the pass later on. On Sat, Oct 2, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > 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 regula...

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