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/