similar to: [LLVMdev] Boehm GC with JIT compiled code

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] Boehm GC with JIT compiled code"

2009 Mar 10
1
[LLVMdev] LLVM JIT + Boehm's GC, Need I Worry?
The virtual machine I'm implementing allocates objects on the heap using Boehm's garbage collector. I currently have an interpreter working for my language, and I'm working on a JIT that will compile some of the functions that would otherwise get interpreted. What I'm wondering is whether or not I need to perform special adjustments for the GC to work properly. My understanding is
2009 Feb 19
0
[LLVMdev] Parametric polymorphism
On Thursday 19 February 2009 03:31:04 DeLesley Hutchins wrote: > > The same can be said of closures, garbage collection and a dozen other > > features that also cannot feasibly be added to LLVM. > > > > The only logical solution is to build a HLVM on top of LLVM and share > > that between these high-level language implementations. > > This is an excellent point.
2008 Jan 07
0
[LLVMdev] GC infrastructure checked in
On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote: > Everything described in GarbageCollection.html should now be live. Phew! > > The collectors could use a review, but they compile, have no impact > unless used, and tests would otherwise have had to be XFAILed waiting > on them. > > The ShadowStackCollector has one issue that may be of interest in that > it adds
2010 Jan 31
2
[LLVMdev] Boehm GC + static variables?
Hi, I'm running LLVM bitcode generated by my compiler under lli. The bitcode is linked against Boehm GC (lli -load=/usr/lib/libgc.so). It looks like Boehm GC isn't scanning global variables and as a result objects referenced only through globals are being prematurely collected. I understand that Boehm GC needs to see the data segment containing my global variables as a root. For native
2010 Jan 31
0
[LLVMdev] Boehm GC + static variables?
I've implemented this by adding calls to GC_add_roots(<first global in module>,<last global in module>+1) to the llvm.global_ctors before any other static initialization code for the module. This should be safe assuming that: - global variables are laid out in memory in the order they appear in their module (and ideally contiguously without being interleaved with any other values)
2009 Feb 19
0
[LLVMdev] VMKit (was Parametric polymorphism)
On Thursday 19 February 2009 13:39:24 Nicolas Geoffray wrote: > Jon Harrop wrote: > > Other people are creating far more bleeding edge VMs (e.g. VMKit) using > > LLVM's GC API so they would be much better positioned to discuss the > > technical aspects than I am. I would like to hear any status updates they > > have! > > VMKit uses conservative GCs (Boehm or
2010 Jan 31
1
[LLVMdev] Boehm GC + static variables?
You should look at http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ExecutionEngine/JITMemoryManager.h?view=markup and see if inheriting from that and overriding allocateGlobal() will do what you want. I'm a little surprised the boehm gc doesn't already see the globals, since there's a reference to their memory from the JMM, but maybe it doesn't scan mmap regions by
2010 Jan 05
2
[LLVMdev] LLVM C bindings and Boehm GC
Hi, I want to use LLVM as replacement code generator for an existing self hosting compiler. I hope to replace the existing BURS code generator with LLVM in order to take advantage of LLVM's JIT, optimizations and wider range of targets. I'm planning on ditching my existing IR completely and using my language's native call mechanism to call the LLVM C bindings. I've got a couple
2009 Feb 19
0
[LLVMdev] Parametric polymorphism
On Wednesday 18 February 2009 23:36:27 DeLesley Hutchins wrote: > > Why do you say that people who compile, e.g., functional languages > > would benefit from type variables in LLVM? > > I like the level the LLVM is at, and would prefer to deal with > > instantiating parametric polymorphism at a higher level. > > I'm surprised you're happy with a
2009 Jan 31
1
[LLVMdev] -msse3 can degrade performance
On Saturday 31 January 2009 03:42:04 Eli Friedman wrote: > On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst > > tweaking the command-line options to llvm-gcc. Specifically, the -msse3 > > flag > > The -msse3 flag? Does the -msse2 flag have a similar effect? Yes: $
2010 Jan 04
0
[LLVMdev] Tail Call Optimisation
On Monday 04 January 2010 03:33:06 Simon Harris wrote: > On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > > I am certainly interested in tail calls because my HLVM project relies > > upon LLVM's tail call elimination. However, I do not understand what tail > > calls LLVM is not currently eliminating that you plan to eliminate? > > Mutual recursion for a start: >
2007 Dec 12
2
[LLVMdev] ocaml binding question
On Monday 10 December 2007 23:52, Gordon Henriksen wrote: > On 2007-12-10, at 18:28, Jon Harrop wrote: > > Incidentally, should more OCaml stuff beyond the bindings be part of > > LLVM or would it be better to fork them into a separate project > > Can you be more specific than "stuff"? I'm thinking of a library that compiles an AST represented by an OCaml data
2008 Feb 14
2
[LLVMdev] Higher-level OCaml bindings
On Thursday 14 February 2008 16:33:25 Chris Lattner wrote: > On Thu, 14 Feb 2008, Jon Harrop wrote: > > Does CLang use a suitable intermediate representation for this to be > > possible? > > The higher level IR that clang uses is basically a C AST. This interface > is under constant flux though. If you wanted to do this, it would be > very reasonable to just cons up
2010 Feb 06
0
[LLVMdev] Removing -tailcallopt?
On Saturday 06 February 2010 02:42:47 Evan Cheng wrote: > On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: > >> Does anyone actually using it? > > > > Yes, many LLVM-based projects rely upon TCO to work correctly. > > Ok, that's all I need to know. > > >> I'd prefer to just remove it to
2009 Mar 28
0
[LLVMdev] Broke my tail (call)
On Tuesday 24 February 2009 14:54:12 Arnold Schwaighofer wrote: > On Tue, Feb 24, 2009 at 11:50 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Thanks for the clarification. That makes a lot more sense! > > > > LLVM's support for structs is wonderful but I don't think they can be > > called "first-class structs" until all such arbitrary
2009 Apr 05
1
[LLVMdev] How the LLVM Compiler Infrastructure Works
I've experienced GCC induced eyeball-clawing.... Not pretty! On Sun, Apr 5, 2009 at 9:37 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Sunday 05 April 2009 06:33:00 Rajika Kumarasiri wrote: > > FYI, > > http://www.informit.com/articles/article.aspx?p=1215438 > > > > -Rajika > > LOL: > > "In contrast, every time I look at the GCC
2010 Feb 17
1
[LLVMdev] LLVM-OCaml Bindings Tutorial (2.6-2.7)
On Tue, Feb 16, 2010 at 2:47 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: >> Does anyone know if there is any realistic project using LLVM-OCaml >> Bindings? > > I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: > >  http://www.ffconsultancy.com/ocaml/hlvm/ > > There
2009 Jan 31
0
[LLVMdev] Performance vs other VMs
----- Original Message ----- From: "Jon Harrop" <jon at ffconsultancy.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Saturday, January 31, 2009 6:56 AM Subject: [LLVMdev] Performance vs other VMs > > The release of a new code generator in Mono 2.2 prompted me to benchmark > the > performance of various VMs using the SciMark2
2009 Jun 22
0
[LLVMdev] SSE examples
----- Original Message ----- From: "Jon Harrop" <jon at ffconsultancy.com> To: <llvmdev at cs.uiuc.edu> Sent: Sunday, June 21, 2009 2:51 PM Subject: [LLVMdev] SSE examples > > Does anyone have any LLVM IR examples implementing things using the > instructions for SSE, like complex arithmetic or 3D vector-matrix stuff? > I don't have any examples... >
2009 Nov 20
1
[LLVMdev] llc barfing
On Friday 20 November 2009 02:54:14 Dan Gohman wrote: > On Nov 19, 2009, at 5:28 PM, Jon Harrop wrote: > > Are these barfs due to bugs in my generated code or is this parts of LLVM > > not honoring tail calls? > > It was a bug in LLVM, with emitting tail calls at -O0. It's now > fixed, as of r89444. Awesome, thanks. What about this one where the simple register