austin at well-typed.com
Wed Oct 23 17:06:56 UTC 2013
*Sigh*. Resending to list from the correct email...
Part of it, probably, is that Hoopl actually costs quite a bit in
terms of efficiency, both in use (e.g. compiler paasses) and
integration (i.e. using the library at all.) Simon Marlow spent quite
a lot of time bringing the new code generator up-to-par with the old
one in terms of compilation time, but it was a tough battle. In
particular, you'll notice all the Monad types from Hoopl are actually
specialized to hell in the compiler, and this is precisely the reasons
for doing so.
On the whole, Hoopl will probably always cost a little more - the new
backend requires more passes due to its design, so there will always
be some cost associated with that. But we only want that cost, and not
the Hoopl overhead itself. :) If you can find a way to introduce new
passes or more flexible optimizations, I'm sure we'd still like to
look at them, though.
On Wed, Oct 23, 2013 at 8:53 AM, Brett Letner <brettletner at gmail.com> wrote:
>> As for the transformations you're trying to implement. You are aware that
>> they are already
>> implemented in GHC but without Hoopl?
> Is that because the ghc code just hasn't been updated yet (no need to if it
> is already working) or because those sorts of transformations are outside
> the scope of what hoopl does (or was intended to do)?
> Thank you,
> ghc-devs mailing list
> ghc-devs at haskell.org
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
More information about the ghc-devs