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