marlowsd at gmail.com
Thu Oct 24 08:35:01 UTC 2013
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.
> 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
More information about the ghc-devs