*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 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, Brett

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

On 23/10/13 18:06, Austin Seipp wrote:

*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.

Correct. Right now, we use Hoopl for analysis only, particularly live-variable analysis. We don't use its transformation capabilities, since even the simplest removeDeadAssignments transformation costs about 5% extra compile time, and I wasn't willing to pay that. The sinking pass that I wrote by hand does a lot more and only costs 3%. Edward Yang's Hoopl version of the sinking pass cost 30%, and that was after I'd wrung everything I could out of hoopl. It ought to be possible to make hoopl faster. One idea I had was to abstract it over the transformation for a whole basic block, rather than for a single instruction. That way you could hand-code the block transformer to take advantage of local knowledge - in particular in most cases we're not splicing entire graphs in place of a single instruction, which is where a lot of the complexity in hoopl comes from. Cheers, Simon

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 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, Brett

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs