Jon Harrop wrote: > My point was that HLVM's data representation is far more flexible than > ocamlopt's,
Would you be able to list those differences for us? > In particular, I am saying that (from my own measurements) LLVM does not > cope with data representations like ocamlopt's at all well. Specifically, > when you box and cast away type information. Yes, thats obviously a mistake when generating typed assembly language like LLVM. > Ultimately, LLVM was built specifically to exploit a typed intermediate > representation whereas ocamlopt removes type information very early. That suggests that a first pass at adding an LLVM backend would be to extend the used of typed data representations through to the backend of the compiler. > And faster tuples, ints, chars, complex numbers, low-dimensional > vectors/matrices, hash tables and so on. More types (e.g. int16 and > float32). So specifically, you keep much more data in unboxed form? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
