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
<simo...@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-boun...@haskell.org [mailto:
> glasgow-haskell-users-
> | boun...@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 <gari...@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-us...@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc@haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
