search for: unboxing

So I now have a working first-order language that uses conventional boxing to handle polymorphism and with ints, floats and ('a -> 'a) functions. After a huge amount of detailed benchmarking in OCaml and F# I have decided that it is very important to be able to unbox complex numbers but no other compound types. As LLVM provides a vector type for power-of-two dimensionalities that

...ml), only single-precision floating-point complex numbers can be unboxed, and only on 64-bit hosts. If you're only interested in complex, would be to compile two copies of each polymorphic function, one for complex numbers, and the other for all other values. To more generally support unboxing, you'll need to look more towards .NET generics and C++ templates for guidance. > Also, do these vectors give significant performance improvements on > x86-64 hardware or are they only good for x86+SSE and relatives? Are there (m)any x64 processors without SSE? — Gordon

On 10/25/13 1:10 PM, Ben Karel wrote: > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com > <mailto:sanjoy at azulsystems.com>> wrote: > > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects

On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote: >>> I don't think you would want to build discriminated unions on top of >>> C-style unions though. >> >> Why? > > Uniformity when nesting and space efficiency. Users of a language > front-end > will want to nest discriminated unions, e.g. to manipulate trees. Okay, so you're just talking about boxed

On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects are invalidated at every > safepoint" somehow in the IR itself. So, if %a and %b are values the > GC is

...d lowered carefully. My operating hypothesis has been to stash barriers at key points - identified by the front-end itself - and possibly elide them during lowering if it's safe to do so. If my understanding is correct, it should be possible to lower the barriers into exactly the kind of boxing/unboxing procedure described in this thread. Based on my experimentation so far, which is admittedly minimal, I think the overhead of updating relocated pointers is actually not as bad as it sounds. It isn't strictly necessary to store both a boxed *and* unboxed pointer in every frame. In fact, in the...

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves

On Friday 02 January 2009 20:48:25 Chris Lattner wrote: > On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: > >> Exactly. I'm not especially interested in C-style unions, I'm > >> interested in discriminated unions. But the actual discriminator field is > >> easily represented in LLVM IR already, so there's no need to extend the > >> IR to support

On Sunday 04 January 2009 01:25:05 Chris Lattner wrote: > On Jan 2, 2009, at 2:29 PM, Jon Harrop wrote: > >>> I don't think you would want to build discriminated unions on top of > >>> C-style unions though. > >> > >> Why? > > > > Uniformity when nesting and space efficiency. Users of a language > > front-end > > will want to

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: >> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union

...d lowered carefully. My operating hypothesis has been to stash barriers at key points - identified by the front-end itself - and possibly elide them during lowering if it's safe to do so. If my understanding is correct, it should be possible to lower the barriers into exactly the kind of boxing/unboxing procedure described in this thread. > > Based on my experimentation so far, which is admittedly minimal, I think the overhead of updating relocated pointers is actually not as bad as it sounds. It isn't strictly necessary to store both a boxed *and* unboxed pointer in every frame. In fac...

...ute this as "mul_ints", "add_ints", "sqrt", etc. Inside these primitive functions we would have to unwrap our IntObj types, add the values, allocate a new object and return that to the function. In the above example, we could probably expect around 4 allocations, and 7 unboxing operations. Now granted if my lanugage is running as a bytecode interpreter, I can speed it up simply by having LLVM call my functions in order, and perhaps even in-lining all the bytecode operations into a single function. But even then, I'm still left with the 4 allocations and 7 unboxings (i...

Hi, At the code below from ./bindings/ocaml/executionengine/executionengine_ocaml.c, we create an OCaml Variant from C. It is from 2.6, the latest 2.7 has the same code. Line 240 Option = alloc(1, 1) assigns tag1 to the 'some' constructor. In term of http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html, I think the 'some' should have a tag 0. We dont have a runtime error for

BLAST! LLVM mailing list headers are still royally screwed up... My message is below... On Sun, Aug 30, 2009 at 2:20 PM, Talin<viridia at gmail.com> wrote: > Hey all, it's been a while since I have posted on this list, but I've > been continuing my work with LLVM and getting lots done :) > > One question I wanted to ask is whether anyone had any advice on how to >

...t I have been considering is rather than generating a pair > of stub functions for each normal function, instead generate a pair of stub > functions for each unique type signature - the idea being that two methods > that have the same calling signature can use the same argument > boxing/unboxing logic. The number of permutations could be reduced further > by weakening the type signature - i.e. convert all pointer arguments to > void* and so on. > > Each stub function would have a function name which is generated from the > type signature of the arguments, and then these func...

...he arguments passed to its immediate caller. Right now I do something like boxing all arguments in the caller inside a struct and passing a pointer to the struct to F, alongside an identifier telling which caller F is being called from. F has then a giant switch that branches to the appropriate unboxing code. This is obviously suboptimal because I need to allocate the struct on the stack, copy the arguments inside of it and then passing an additional pointer to F. I was wondering if there's a better way to do this, e.g. a way to access the stack frame of the caller (knowing, thanks to the...

On Sun, Feb 28, 2010 at 8:38 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Hi, > > At the code below from > ./bindings/ocaml/executionengine/executionengine_ocaml.c, > we create an OCaml Variant from C. It is from 2.6, the latest 2.7 has > the same code. > > Line 240 Option = alloc(1, 1) assigns tag1 to the 'some' constructor. > In term of

Move the code for handling machine readable up in the file, so it can be used by other functions. Only code motion, no behaviour changes. --- common/mltools/tools_utils.ml | 60 +++++++++++++++++------------------ 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/common/mltools/tools_utils.ml b/common/mltools/tools_utils.ml index 24641369e..5a35708cd 100644 ---

...cases (probably non-GC-intensive numeric code) would be an incredibly compelling demo for the use of LLVM in general compiler writing. This looks perfectly feasible to me. I got the impression from some of the blurb that I read that the optimizer in LLVM might even be able to automate localized unboxing. Is that true? If so, that would make things a lot easier... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

To illustrate the value of value types to the OCaml community I recently did a couple of benchmarks. The first was similar to a hash table and stores key-value pairs unboxed in an array: http://groups.google.com/group/fa.caml/msg/8430ebdb687b9268 The second is the hailstone benchmark that the Haskell guys found gave huge performance improvements when using LLVM from GHC: