inside the GHC code generator

[Rene de Visser]

>From: Bulat Ziganshin <bulat.ziganshin at gmail.com>
>
>Hello Rene,
>

>i done reading. my question - is YOU read this? the lisp problems have 
>almost
>nothing in common with haskell

It is a long time since i read this, but some things come to mind. Listed 
below.

Maybe GHC should generate better C. I am just not sure whether this will 
bring the best global (as opposed to micro-optimizations) performance. 
However doing anything else might be difficult.

Generating better C might also be much more difficult for idioms that don't 
exist in C, and might encourage people to write Haskell that looks like C 
(in order to get C like performance).

I prefer idiomatic Haskell. It would be nice if this could be fast. But can 
idiomatic Haskell be translated to efficient C? It might not have many 
direct loops for example.

-- Other notes

Integer is about 30 times slower than it needs to be on GHC if you have over 
half the values between 2^-31 and 2^31. On i386 can you basically can test 
the low bit for free (it runs in parallel to the integer add instruction). 
This would allow only values outside this range to required calling the long 
integer code. Such an optimization is not easily done in C.

This encourages Haskell programmers to always use Int, even if the value 
might get too big, because Integer is too slow.

Also Tail recursion is more general than looping. A general tail call 
optimization will bring better returns than a loop optimization in GHC 
(though I could be wrong here). This requires special stack handling. Also 
not so easy in C.

If only simple loops are optimized it will encourage people to always code 
loops in their haskell rather than perhaps using more appropriate 
constructs.

Also take the Maybe data type with Nothing and Just ... or any other 
datatypes with 0 and 1 variable constructors. Here these could be represent 
by special values for the 0 variable case and bit marking on the single 
constructor values. This could lead to good optimizations on case 
expressions.
Also not so easy in C.

The lack of this feature encourages people to encode their datatypes as 
Int's to get speed. Also not good.

Whether we can communicate the non aliasing and aliasing properties of GHC 
to the C compiler, I am also not so sure.

Also in GHC, I am not sure whether stack base locals are the best move. It 
might be best to have a fixed page as register spill in some cases.

If you wish to pass and return unboxed tuples without reboxing you will 
probably required a special function interface with double entry points (I 
think this can be done in C, but it is  a bit tricky).

Summary: If only C like Haskell is fast, we end up with Haskell that looks 
like C. Yuck.

Rene.