(Narrowing to just cvs-ghc for now) I found a draft of Krzysztof’s dissertation, which I’ve put up here http://research.microsoft.com/en-us/um/people/simonpj/tmp/wos-diss-draft.pdf. I’ve asked him for the final version, but he hasn’t responded yet.
Simon From: Carter Schonwald [mailto:carter.schonw...@gmail.com] Sent: 11 December 2012 21:23 To: Simon Peyton-Jones Cc: Johan Tibell; Greg Fitzgerald; cvs-ghc@haskell.org; GHC Users Mailing List Subject: Re: Hoopl vs LLVM? 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<mailto: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> [mailto:glasgow-haskell-users-<mailto:glasgow-haskell-users-> | boun...@haskell.org<mailto: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<mailto: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<mailto:glasgow-haskell-us...@haskell.org> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org<mailto: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
