Re: [Caml-list] unboxing of unary datatypes

[Florian Hars <hars@bik-gmbh.de>]

Nicolas Cannasse wrote:
>>Can someone explain this to me?  Why doesn't the compiler optimize out the
>>constructor?
> Because they don't have the same C raw representation.
> There is one more indirection when you use a constructor.

No, I think he sees something different here: The compiler does in fact 
optimize out the constructor and then operates directly on the value (which, in 
this case, is a boxed float). But it does not perform the special float 
optimizations it does on values of the types float, float array and
records like { x: float; y: float; ... (* All fields are floats *)} (but not on 
tupels and sum types containing floats).

(Maybe something like the last part of 
http://caml.inria.fr/archives/200105/msg00174.html should be added to the 
efficiency part of the expert FAQ).

You can see the difference if you compile

type foo = Foo of float

let addpair x y = match x, y with
   (a,_), (b, _) -> a +. b

let addfoo  x y = match x, y with
   Foo x', Foo y' -> x' +. y'

let add x y = match x, y with
   x', y' -> x' +. y'

with ocamlc -dinstr -c foo.ml: The code for addfoo is exactly the same as the 
code for addpair and does not check any contructors, but accesses the values 
with getfield without checking their types or any constructors again (the 
compiler knows they are floats):

L2:     grab 1
         acc 1
         getfield 0
         push
         acc 1
         getfield 0
         ccall add_float, 2
         return 2

add, on the other hand, is treated specially by the float optimizer and gets 
away without the unboxig getfield calls:

L1:     grab 1
         acc 1
         push
         acc 1
         ccall add_float, 2
         return 2

Yours, Florian Hars.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners