similar to: [LLVMdev] Calculating relative sizes of globals in IR

Hi Talin, I too agree 100% with Dan's words, and this could be a good pointer for Jin-Gu Kang to continue on his pursuit for a better target-independent bitcode. Also, add your backwards compatibility issue to debug metadata in IR, in which fields appear or disappear without notice. But I think you hit a sweet spot here... On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote:

On Tue, Oct 4, 2011 at 3:54 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu>wrote: > On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at systemcall.org> > wrote: > > Hi Talin, > > > > I too agree 100% with Dan's words, and this could be a good pointer > > for Jin-Gu Kang to continue on his pursuit for a better > > target-independent bitcode.

On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi Talin, > > I too agree 100% with Dan's words, and this could be a good pointer > for Jin-Gu Kang to continue on his pursuit for a better > target-independent bitcode. > > Also, add your backwards compatibility issue to debug metadata in IR, > in which fields appear or disappear

Talin wrote: > On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com > <mailto:viridia at gmail.com>> wrote: > > I notice that there's a lot of inconsistency in the various LLVM > classes with respect to convenience methods. Here's some examples: > > For creating GEPS, IRBuilder has: > > CreateGEP (2 overloads) >

On Wed, Feb 2, 2011 at 1:29 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Talin wrote: > >> On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com >> <mailto:viridia at gmail.com>> wrote: >> >> I notice that there's a lot of inconsistency in the various LLVM >> classes with respect to convenience methods. Here's some

On Mon, Oct 11, 2010 at 11:12 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 11, 2010, at 11:04 AM, Talin wrote: > > On Mon, Oct 11, 2010 at 10:43 AM, Chris Lattner <clattner at apple.com>wrote: > >> >> On Oct 11, 2010, at 8:17 AM, Devang Patel wrote: >> >> >> Interestingly enough, I just upgraded to the latest Ubuntu (10.10 -

Jeffrey and I are working on future standard library functionality for hashing user defined types: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3333.html I would much rather have an interface that is close to or mirrors this one. We already have some field experience with it, and using it in LLVM and Clang would provide more. Also, it would be possible to essentially share code

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

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, Apr 21, 2011 at 2:43 PM, Eric Christopher <echristo at apple.com>wrote: > > On Apr 20, 2011, at 4:34 PM, Talin wrote: > > > Also, looking in the SVN repo, it appears that some of the files in > include/llvm/ExecutionEngine have not been touched in a long time, and that > scares me a bit - what's the current state of the LLVM interpreter? > > > >

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"

Chris Lattner wrote: > On May 5, 2009, at 8:09 PM, Talin wrote: > > >> I wanted to mention, by the way, that my need/desire for this hasn't >> gone away :) >> >> And my wish list still includes support for something like uintptr_t >> - a >> primitive integer type that is defined to always be the same size as a >> pointer, however large or

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

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 common hashing facility, there will be an increasing proliferation of cut & paste copies of hash functions. So feedback would be nice. On Tue, Feb 7, 2012 at 10:58 PM, Talin <viridia at

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,

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: > >>

On Tue, Oct 4, 2011 at 5:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 4, 2011, at 4:56 PM, Talin wrote: > > > LLVM isn't actually a virtual machine. It's widely acknoledged that the >> > name "LLVM" is a historical artifact which doesn't reliably connote what >> > LLVM actually grew to be. LLVM IR is a compiler IR.

On Sat, Sep 25, 2010 at 10:51 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > 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. So the patch is OK then? All it does

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

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > 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: