Unexpected lack of optimisation

Sittampalam, Ganesh ganesh.sittampalam at credit-suisse.com
Wed Apr 30 03:38:52 EDT 2008

Simon Peyton Jones wrote: 

> | It worked, with:
> |
> | {-# INLINE [1] begin1 #-}
> | {-# INLINE begin2 #-}
> |
> | I don't think this approach will compose particularly well, and in
> | real case I was trying (not this reduced example) I don't think it 
> | will work because there is some recursion and RULES involved. I'll 
> | have another go with the full example in future.

> I agree it's not great.  But I just don't have a better idea at the
> In the general case I showed, it seems hard to know what to do.
> there are better rules for special cases. If you have good ideas, I'm
> ears!

I've thought for a while that the phase system is going to cause trouble
when people start trying to build self-optimising libraries on top of
other self-optimising libraries like ByteString.

Instead of specifying absolute phase numbers, could a partial ordering
be specified somehow, and have GHC pick the actual phases? One way of
doing this would be replace [1] with [Symbol] where Symbol would be some
normal Haskell entity (e.g. an empty datatype) and could be  exported,
and add a pragma to specify orderings.

I can see two problems with this:

 - The ordering would be (deliberately) underspecified, so optimisations
   might become unstable if it changed suddenly.
 - GHC might not have enough phases to actually assign all symbols to
   phases. I don't know if it would be easy to make the number of phases



Please access the attached hyperlink for an important electronic communications disclaimer: 


More information about the Glasgow-haskell-users mailing list