search for: unboxed

...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 from them or must I add an indirection via a pointer? Also, do these vectors give significant performance improvements on x86-64 hardware or are they only good for x86+SSE and relatives? -- Dr Jon D H...

...g 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 from them or must I add an indirection via a > pointer? Bitcast simply depends on storage size. If two first-class types are of the same size, you can bitcast. If not, you can't. P...

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

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

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

...arriers 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 current incarnation of gcroot, marking an alloca as a gcroot effectively forces a stack spill for that alloca; this means that the relocating collector just updates the single existing pointer on the stack when it does its magic, and you're done. With pro...

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

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

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

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

...to 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 current incarnation of gcroot, marking an alloca as a gcroot effectively forces a stack spill for that alloca; this means that the relocating collector just updates the single existing pointer on the stack when it does its magic, and you're done. With pro...

In the creation of dynamic languages we often have to box values together. For instance, take the following expression: IntObj c = sqrt((a*a)+(b*b)); Here, most likely, a bytecode interpreter would execute 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

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

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

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

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

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