search for: unboxings

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

On Nov 29, 2007, at 16:06, Jon Harrop wrote: > So I now have a working first-order language that uses conventional > boxing to handle polymorphism and with ints, floats and ('a -> 'a) > functions. Cool. > 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

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

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

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

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

...d 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 (is that even a word?). I know other compiler projects, such as PyPy have allocation removal where the optimization passes see that we only use the result of an allocation a single time. Thinking that LLVM may do this as well, I tried this simple test on in-browser LLVM compiler: -------- #include...

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 >

Blast! LLVM mailing server *still* has the headers broken... On Mon, Aug 31, 2009 at 11:03 PM, Talin<viridia at gmail.com> wrote: > OvermindDL1 wrote: >> >> 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: >> >>>

I need some advice on "forwarding" arguments to a callee. Suppose I have a function F that is called at the beginning of all other functions in the module. From F I need to access (read) the 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

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

On Sunday 25 November 2007 21:00, Chris Lattner wrote: > >> Lexing is the one issue though. > > > > How do you mean? > > I think he's observing that a majority of the tutorial code is > actually spent on the lexer and parser, not on the llvm-specific pieces. Right. > > I'm just fiddling around with it now. The lexer, parser and AST > > written

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: