| 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
