similar to: [LLVMdev] GC in multithreaded (but with no shared state) environment

>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 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 codegen. If I don't give LLVM the same information the x86 codegen has, it's an unfair comparison.

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 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 codegen. If I don't

Hi llvm-dev, I read about volatile and atomic modifiers in the docs[1], and I feel they make sense to me individually. However, I noticed that store[2] and load[3] instructions can be marked as both volatile and atomic. What's the use case for using both volatile and atomic on an instruction? Isn't it the case that atomic implies volatile? I guess it isn't, but I don't understand

Hi all, I've been working recently on a precise garbage collector which runs alongside native code JITted by LLVM. Today marks the first time the GC has passed its entire test suite as well as extensive soak tests in non-trivial programs. It's been an interesting and educational process, to say the least, and I've run into quite a few things that might be useful to know for others

Hi Tim, On 20 November 2017 at 16:41, Tim Northover <t.p.northover at gmail.com> wrote: > There are only a couple of valid uses for volatile these days Do you mean volatile used alone or also the combination 'atomic volatile'? It think that 'atomic volatile' is very useful. Consider following pseudo-code examples, where all loads and stores are atomic (with some memory

On Sat, Sep 20, 2008 at 9:57 AM, Jon Harrop <jonathandeanharrop at googlemail.com> wrote: > I think your new OCaml tutorials and the original C++ ones are absolutely > brilliant! Thanks Jon. I'm sorry I missed this message. Now that you've had some more experience with llvm, would you be interested in adding to the doc some performance and GC stuff? I haven't personally

Hi Talin, I wrote HLVM: http://www.ffconsultancy.com/ocaml/hlvm/ The whole project took a few man months. HLVM provides an ML-like type system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, POSIX threads, mark-sweep GC and both JIT and standalone compilation. I wrote several (accurate) garbage collectors for it including a stop-the-world mark-sweep collector and they

On Monday 31 March 2008 09:56:45 Erick Tryzelaar wrote: > The full series of the ocaml tutorial is done! You can find it here: > > http://llvm.org/docs/tutorial/ > > Please let me know if you have any comments, bugs, suggestions, and > etc. I'll send a mail to the ocaml mailing list tomorrow to drum up > some interest from the other ocaml users. I think your new OCaml

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,

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, I've been looking at all of the uses of the 'unwind' instruction, and ShadowStackGC.cpp is the last pass which actually creates 'unwind' instructions. The thing is, this pass seems to be dead. It hasn't been updated in any meaningful way since ~79000. Should this pass go the way of the dodo? -bw -------------- next part -------------- A non-text attachment was

Good afternoon! I'm trying to write an LLVM codegen for a Standard ML compiler (MLton). So far things seem to match up quite nicely, but I have hit two sticking points. I'm hoping LLVM experts might know how to handle these two cases better. 1: In ML we have some types that are actually one of several possible types. Expressed in C this might be thought of as a union. The codegen only

> 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. You have convinced me. :-) BTW, what garbage collector are you using for your HLVM? You

Comments inline. On Sun, Dec 4, 2011 at 1:38 PM, Jon Harrop < jonathandeanharrop at googlemail.com> wrote: > Hi Talin, > > I wrote HLVM: > > http://www.ffconsultancy.com/ocaml/hlvm/ > > The whole project took a few man months. HLVM provides an ML-like type > system, unboxed tuples, discriminated unions, TCO, generic printing, C FFI, > POSIX threads, mark-sweep

> 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 non-polymorphic llvm. Does Cayenne target llvm? Dependent types take polymorphism to new heights -- but

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a

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

Am 16.12.2011 21:06, schrieb Jon Harrop: > At regular intervals, check if the heap size has exceeded its quota > and, if so, run a GC cycle. I have seen people recommend doing this kind of check whenever hitting a malloc call. I think it nicely scales with the level of heap activity for most programs.