(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

Reply via email to