Hoopl vs LLVM?

[Carter Schonwald]

Cool info!
Would love to see that report if you can dig it up :)
-Carter


On Tue, Dec 11, 2012 at 2:16 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

> |  In my opinion we should only implement optimizations in Hoopl that
> |  LLVM cannot do due to lack high-level information that we might have
> |  gotten rid of before we reach the LLVM code generator*. I don't think
>
> Indeed.  And I think there is probably quite a lot that is in reach for
> C--, but out of reach for LLVM.  Why?  Because before we pass the code to
> LLVM we do CPS-conversion.  So code that started like this:
>         f() {
>                 x = blah
>                 z = blah2
>                 p,q = g(x)
>                 res = z + p - q
>                 return res
>         }
> Turns into something more like  this:
>         f () {
>                 x = blah
>                 z = blah2
>                 ...push z on stack...
>                 ...push fr1 onto stack...
>                 jump g(x)
>         }
>
>         fr1( p,q ) {
>                 z = ...pop from stack...
>                 res = z + p - q
>                 return res
>         }
>
> Notice that the stack is now *explicit* rather than implicit, and LLVM has
> no hope of moving the assignment to z past the call to g (which is trivial
> in the original).  I can explain WHY we do this (there is stuff on the
> wiki) but the fact is that we do, and it's no accident.
>
> Some transformations and optimisations are only possible before the CPS
> conversion, which means LLVM can't do it.  There is real meat here.
>
> Moreover, one of Simon M's last acts was to switch to the "new codgen
> path", which uses the new C-- rep etc.  That leaves us *ready* to do some
> traditional-style optimisations on C--, but we have not *actually done* so.
>   The field is wide open.
>
> For example, I had a masters student three years ago (Marcej Wos) who
> implement the classic tail-call-becomes-loop optimisation, and got a
> surprisingly large benefit.  His code is rotted now, but I must dig out his
> Masters project report which described it all rather well.
>
> In short, go for it.  But as Johan says, concentrate on things that LLVM
> can't get.
>
> Simon
>
> |  -----Original Message-----
> |  From: glasgow-haskell-users-bounces at haskell.org [mailto:
> glasgow-haskell-users-
> |  bounces at haskell.org] On Behalf Of Johan Tibell
> |  Sent: 10 December 2012 22:40
> |  To: Greg Fitzgerald
> |  Cc: GHC Users Mailing List
> |  Subject: Re: Hoopl vs LLVM?
> |
> |  On Mon, Dec 10, 2012 at 2:24 PM, Greg Fitzgerald <garious at gmail.com>
> wrote:
> |  > Should one group be stealing ideas from the other?  Or apples and
> oranges?
> |
> |  In my opinion we should only implement optimizations in Hoopl that
> |  LLVM cannot do due to lack high-level information that we might have
> |  gotten rid of before we reach the LLVM code generator*. I don't think
> |  we should spend time re-implementing LLVM passes in Hoopl. We have
> |  limited time on our hands (much less than the LLVM team) and we're
> |  unlikely to do a better job than them here, as we're talking about
> |  implementing standard, imperative code optimization. I think our time
> |  is better spent on 1) making sure we pass enough information to LLVM
> |  for it to do a good job and 2) working on higher-level optimizations
> |  (e.g. Core-to-Core).
> |
> |  * This also means that I think we should try to preserve any
> |  information LLVM might need all the way down to the code generator.
> |
> |  -- Johan
> |
> |  _______________________________________________
> |  Glasgow-haskell-users mailing list
> |  Glasgow-haskell-users at haskell.org
> |  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121211/0cf1f910/attachment-0001.htm>