search for: unbox

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 compiles to efficient parallel code, I'd like to know if I can store them unboxed in a way that is equivalent to my ints, floats and function pointers, i.e. can I cast to and f...

...w 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 compound types. As LLVM provides a vector type > for power-of-two dimensionalities that compiles to efficient > parallel code, I'd like to know if I can store them unboxed in a way > that is equivalent to my ints, floats and function pointers,...

...; pointer's value at a given point in time. So, of course, whenever that > object pointer's value might change, there must be a new name. To rephrase, you're saying that the current gcroot mechanism is analogous to a boxed object pointer. We could model a safepoint by storing the unboxed value into the box, applying an opaque operation to the box, and reloading the raw object pointer from the box. (The opaque operator is key to prevent the store/load pair from being removed. It also implements the actual safepoint operation.) Is this a correct restatement? Here's an e...

...criminated 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 vs unboxed discriminated unions, or "by ref" vs "by value" discriminated unions. Clearly the LLVM IR support for "c style unions" would only be useful for "unboxed" or "byvalue" discriminated unions. That doesn't mean that *your* specific uses...

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

...at a > given point in time. So, of course, whenever that object pointer's value > might change, there must be a new name. > > To rephrase, you're saying that the current gcroot mechanism is analogous > to a boxed object pointer. We could model a safepoint by storing the > unboxed value into the box, applying an opaque operation to the box, and > reloading the raw object pointer from the box. (The opaque operator is key > to prevent the store/load pair from being removed. It also implements the > actual safepoint operation.) Is this a correct restatement? >...

...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. C-style unions are designed to be unboxed so they are useless for that unless you introduce pointer indirections but if you store all unions by reference then the uniformity of the 1-word pointer size obviates the need to use same (largest) size union cases so you would drop C-style unions in favor of a more space-efficient alternati...

...gt; 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 vs unboxed discriminated > unions, or "by ref" vs "by value" discriminated unions. Clearly the > LLVM IR support for "c style unions" would only be useful for > "unboxed" or "byvalue" discriminated unions. That doesn't mean that > *your* sp...

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

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

...n = 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 this, the reason might be there is only two constructors, one is None represented as unboxed int, the other is Some represented as a tagged block, and OCaml runtime may only distinguish them as the structures, but not the tag number. Zjz 233 /* string -> ExecutionEngine.t -> llvalue option */ 234 CAMLprim value llvm_ee_find_function(value Name, LLVMExecutionEngineRef EE) { 235...

...be > intercepted. In the case of Java and C#, the VM is able to box all of > the arguments that are primitive types, and pass to the handler method > an array of type Object[]. Similarly, one can call method.invoke() on a > method, passing in that same array of objects, and the VM will unbox the > primitive types and then call the actual method with the right argument > types. > > One obvious way to do this is to generate two stub functions for every > function emitted by the compiler, one that takes the original argument > signature and creates a list of boxed object...

...the case of Java and C#, the VM is able to box all of >>> the arguments that are primitive types, and pass to the handler method >>> an array of type Object[]. Similarly, one can call method.invoke() on a >>> method, passing in that same array of objects, and the VM will unbox the >>> primitive types and then call the actual method with the right argument >>> types. >>> >>> One obvious way to do this is to generate two stub functions for every >>> function emitted by the compiler, one that takes the original argument >>&...

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

...gns 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 this, the reason might be there is only two constructors, one > is None represented as unboxed int, the other is Some represented > as a tagged block, and OCaml runtime may only distinguish them > as the structures, but not the tag number. Sounds reasonable. I'll make the change to make things more consistent. Also, I see that we aren't properly protecting our option values...

...nit = "guestfs_int_mllib_set_echo_keys" "noalloc" external c_set_keys_from_stdin : unit -> unit = "guestfs_int_mllib_set_keys_from_stdin" "noalloc" +type machine_readable_fn = { + pr : 'a. ('a, unit, string, unit) format4 -> 'a; +} (* [@@unboxed] *) + +type machine_readable_output_type = + | NoOutput + | Channel of out_channel + | File of string +let machine_readable_output = ref NoOutput +let machine_readable_channel = ref None +let machine_readable () = + let chan = + if !machine_readable_channel = None then ( + let chan =...

...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: http://groups.google.com/group/fa.caml/msg/b62e9ba363cd10ee Surprisingly, the hailstone b...