[LLVMdev] Boxing and vectors

[Gordon Henriksen]

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 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. Pointers are the  
only exception; those require a combination bitcast/inttoptr or  
ptrtoint/bitcast to cover all possible conversions.

On 32-bit platforms, these first-class types are bitcastable to one  
another:

i32, float, any*, <2 x i16>, <4 x i8>

On 64-bit platforms:

i64, double, any*, <2 x float>, <2 x i32>, <4 x i16>, <8 x i8>

So to utilize erasure-based polymorphism (as in Java or Ocaml), only  
single-precision floating-point complex numbers can be unboxed, and  
only on 64-bit hosts. If you're only interested in complex, would be  
to compile two copies of each polymorphic function, one for complex  
numbers, and the other for all other values. To more generally support  
unboxing, you'll need to look more towards .NET generics and C++  
templates for guidance.

> Also, do these vectors give significant performance improvements on  
> x86-64 hardware or are they only good for x86+SSE and relatives?


Are there (m)any x64 processors without SSE?

— Gordon