Unexpected lack of optimisation

[Sittampalam, Ganesh]

Simon Peyton Jones wrote: 

> | It worked, with:
> |
> | {-# INLINE [1] begin1 #-}
> | {-# INLINE begin2 #-}
> |
> | I don't think this approach will compose particularly well, and in
the 
> | 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
moment.
> In the general case I showed, it seems hard to know what to do.
Perhaps
> there are better rules for special cases. If you have good ideas, I'm
all
> 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
   dynamic.

Cheers,

Ganesh

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

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================