search for: mlton

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.

Thanks to help in a previous thread, I now have a working LLVM codegen for the MLton compiler. Currently the stack is managed explicitly on the heap. This way the LLVM codegen re-uses the runtime layout of the other codegens, simplifying the initial porting effort. In the next phase I plan to switch to using LLVM to manage the stack, but there is a sticking point: MLton switches s...

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

>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 give LLVM the same information >> the x86 codegen has, it's an unfa...

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: > > > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta- > >04.html...

...trapped an SML compiler for FreeBSD/ppc this way a while back. A part of the compiler was written in SML and there was an option to compile SML to C (that was actually one of the ways to generate final code: the C output would then be passed to a system C compiler). I think the SML compiler was mlton, but I'm not 100% certain. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hello All (to Ocaml List & CC LLVM list) As some might probably know, the LLVM compiler http://llvm.org/ has (at least in its latest SVN snapshot) a binding for Ocaml. This means that one could code in Ocaml some stuff (eg a JIT-ing compiler) which uses (and links with) LLVM libraries. http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011481.html

...es, absolutely! ThinLTO and PGO are largely orthogonal, but PGO will help enable more indirect call promotion with ThinLTO, and there is also a patch out for review (D24638) to use FDO to guide ThinLTO function importing heuristics. > What would be more fun is combining ThinLTO for C code with MLton > for SML code when building Ur/Web. > Interesting. I am not at all familiar with SML code/building, but theoretically switching the C code to use -flto=thin shouldn't affect the interaction between those two compiles. Presumably one or both are compiled into a library and linked in to c...

...makes it easy to avoid the cost of polymorphism by generating > code for each permutation of type variables that a definition is used with. > That immediately removes the cost of polymorphism because we get a version of > fold specialized for float arrays. > I'm fairly certain that MLton does this during static compilation.

...istinct LLVM type for every ML union type >> and each of its constructors.  Unfortunately, LLVM does structural >> uniquing of types, so that won't work. > > Is there absolutely no way to generate a new type? Not even an > 'opaque' one? Is this really a problem for MLton? I think you only get less precise alias analysis, and that's it.

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

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

No worries, thanks for the update. Teresa On Mon, Sep 26, 2016, 7:16 AM Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 3:52 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > ThinLTO needs to create as many temporary files as there are input > > modules to the link. From your 'ls' below, it doesn't look

On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com> wrote: > On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote: > Currently I just represent %c as i8*. I assume that this can have > consequences in terms of aliasing. I tried opaque*, but llvm-as didn't > like that. Is there any way to better represent the type %c to LLVM? > > I assume this is for

On Sunday 28 December 2008 05:53:55 Talin wrote: > The second solution is that when calling via a pointer, we always call > with the closure protocol, i.e. we include the hidden parameter. > However, when taking the address of a non-closure function, we actually > point to a stub function which strips off the hidden parameter before > calling the real function. This solution is

A somewhat random question: I'm wondering if there's any kind of trick in LLVM that would allow me to implement closures efficiently. We can assume that a closure function has a hidden parameter which points to its environment, that is, the values of the variables which were in scope at the point where the closure function was defined. The problem comes when mixing closure and

Hi, This is not the purpose of my distro. The purpose of my distro is to account for complexity lock-in and to remove this as much as possible. This complexity is usually performed in 2 ways: - ultra costly languages/runtime to implement (c++/java...), and I don't think "ultra" is a word big enough. - multiplication of script languages

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