similar to: [LLVMdev] ShadowStackGC.cpp - More Dead Code?

Hi Bill, I don't think it's dead code, per se -- AFAIK there are still clients of LLVM which use the shadow stack as part of their garbage collection implementation. HLVM is probably the most visible such project. My own project now has its own GC plugin to emit stack maps, rather than relying on the shadow stack. But for what it's worth, I found the shadow stack to be a useful

Hi all, I'm toying around with LLVM's GC support and am struggling with the following. I have a little test snippet (a .ll file with IR) that uses llvm.gcroot to mark a GC root, but when I compile it to assembly with llc, followed by generating an executable with gcc I get an error related to exception handling: 22:40|melis at juggle2:~/projects/llvm_gc> cat root.ll %obj = type { i8*,

So I've been using LLVM for about 4 years now, and I've posted a lot on this list about specific issues. What I would like to do is step back for a moment and give my "big picture" assessment of LLVM overall, particularly with respect to developing a "managed" language like Java / C# or my own language, Tart. Obviously, I feel that LLVM is the best choice out there,

G'Day, I've been looking at our minimum python version for the AD DC. We have some patches currently being proposed to help us become compatible with the modern Python3, and one aspect (PyCapsule) would be easier to do if we restricted Samba to requiring Python 2.7 as a minimum. The wrinkle comes from our good friends at Red Hat, which found itself caught with Python 2.6 on RHEL6.

Jon Harrop wrote: > The simplest way is surely to reuse HLVM because it provides everything you > need and is even written in the right language! ;-) Is there a web page with HLVM docs? There's a README.txt in the subversion repository: https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt which says: HLVM comes with documentation in HTML format. These are provided in

What happened to the HLVM project? I understand it was intended to be a high-level VM specifically for dynamic languages and this post indicates that it was integrated into the LLVM project last year: http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html But I cannot find any code in LLVM that looks like it would have come from HLVM. -- Dr Jon Harrop, Flying Frog Consultancy

I expected the row names to be unique but a data frame appears to be able to hold duplicate row names. This makes me thing that there must be circumstances when it is necessary. However, I cannot think of any. Please enlighten me. [[alternative HTML version deleted]]

I took the first two lines of the sample program in the tutorial: hendrik at lovesong:~/dv/lang/hlvm$ cat broken.cpp #include "llvm/DerivedTypes.h" #include "llvm/Module.h" hendrik at lovesong:~/dv/lang/hlvm$ and tried to compile them using the llvm-dev in Debian testing: hendrik at lovesong:~/dv/lang/hlvm$ g++ -o broken.o -c broken.cpp In file included from

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: >> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: >> > Is this really a problem for MLton? I think you only get less precise >> > alias analysis, and that's it. >> >> Correct. However, I want a fair comparison between LLVM performance >> and the native x86

On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: > On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote: [...] > This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the

Someone is trying to work on HLVM with me but they're hitting a problem that we have not been able to resolve. Specifically, GCC seems to be performing some kind of sanity check for "stack smashing" and is calling abort because it is unhappy with something that the code is doing. However, I am not sure what and cannot reproduce the problem. The stack trace they have given me is:

Hi all, I would like to implement GC for a language supporting multiple threads. There will be no shared state between threads as communication will be based on message passing. I do not care much about performance. The priority for me is to get things working. I have read LLVM guide on writing GC: http://llvm.org/docs/GarbageCollection.html. Shadow stack approach looks very promising. The

Hi, I am senior student at Tashkent University of Information Technologies and I am highly interested in programming language design. I want to develop Python front-end for HLVM as a part of LLVM participation in Google Summer of Code project. I am in long love with Python programming language for its simplicity and effectiveness. Last year I noticed ShedSkin Python to C++ translator among SoC

On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote: > Jon Harrop wrote: > >Even if this puts LLVM at an unfair disadvantage, I think you will find > >that > >LLVM will thrash MLton's current x86 backend anyway. > > > >I did some benchmarking on HLVM and found that it was often several times > >faster than OCaml when the GC is not the bottleneck: > >

On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: > On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block

You need to use the script 'llvm-config' to pass correct arguments to g ++: g++ -o broken.o `llvm-config --cxxflags` broken.cpp On Jun 2, 2008, at 9:43 AM, Hendrik Boom wrote: > I took the first two lines of the sample program in the tutorial: > > > hendrik at lovesong:~/dv/lang/hlvm$ cat broken.cpp > #include "llvm/DerivedTypes.h" > #include

Talin wrote: > Jon wrote: > > Talin wrote: > > > Garbage collection is still way too difficult. > > > > This is completely untrue. > > I'm afraid I'm going to have to disagree... I failed to get my point across. You're still talking about the difficulty of using LLVM's GC support. I was talking about circumventing it. The shadow stack HLVM uses

Greetings, I'm trying to implement exception handling in my front end. I have a prototype working using the Itanium ABI on Linux x86_64, but I'm not sure how to proceed for other platforms. So I was wondering: which OS/architecture combinations support zero-cost EH, and which support SJLJ? My main concern is keeping the IR for call sites platform independent. Right now, it looks like to

[This email is either empty or too large to be displayed at this time]

Hi All, I have a query regarding LLVM,Can LLVM IR can restore high level information of base language. Thanks and Regards, Manish On 5/18/07, manish <manishagg22 at gmail.com> wrote: > >