hoopl questions

[Simon Marlow]

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 <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,
>> Brett
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>