Removing Hoopl dependency?
Michal Terepeta
michal.terepeta at gmail.com
Sat May 27 17:58:11 UTC 2017
Hi all,
I was looking at removing the `BlockId` type synonym in favor of
Hoopl's `Label` (there was already a TODO and it is a bit confusing).
But once I've started making the changes, I've realized that in a
bunch of places this makes the code *less* readable. Mostly because of
`CLabel` (sounds similar but is something quite different and having
to rename local variables from `label` to `clabel` is not great).
I started to look at alternatives and noticed that in general the
interface between GHC and Hoopl is quite noisy and confusing:
- Hoopl has `Label` which is GHC's `BlockId` but different than
GHC's `CLabel`
- Hoopl has `Unique` which is different than GHC's `Unique`
- Hoopl has `Unique{Map,Set}` which are different than GHC's
`Uniq{FM,Set}`
- GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is
needed just to filter the exposed functions (filter out some of the
Hoopl's and add the GHC ones).
- Working in `cmm/` requires constant switching between GHC code and
Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC,
the actual implementation of `Block`/`Graph` are defined in Hoopl,
etc.)
GHC is actually using only a small subset of Hoopl (e.g., the fixpoint
computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was
wondering - maybe it's worth to simply drop the dependency on Hoopl?
(and copy the code that is actually necessary in GHC)
I've done an experiment in [1] (to see how much we'd need to actually
copy) and I really like the result:
- We can remove one external dependency and git submodule at the
cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4
modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer
needed)
- We should be able to fix all of the above issues and make the code
easier to understand (less code, everything in one repo, fewer
concepts).
- It's going to be easier to change things since we don't need to
worry about changing the public interface of Hoopl (it's a
standalone package on Hackage and other people already depend on the
current behavior).
What do you think? Does anyone think we shouldn't do this?
Thanks,
Michal
[1] Branch: https://github.com/michalt/ghc/tree/hoopl/no-hoopl
Diff: https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hoopl
For now I just copied the code/updated imports and didn't do any
cleanups, but I'd be happy to do them in subsequent PRs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170527/e6547268/attachment.html>
More information about the ghc-devs
mailing list