Merge Request: LLVM Code Generator for GHC
davidterei at gmail.com
Wed Feb 24 19:08:13 EST 2010
Simon Marlow wrote:
> So, nofib programs are on average 4-5% slower, with a 6% increase in
> binary sizes (this is with -split-objs).
> What's interesting is that there are some outliers here: programs that
> go 12-17% slower without TNTC. Looking at David's thesis the results are
> quite different. Perhaps it is processor dependent?
I ran nofib again and am getting results similar to yours. I have
all the nofib runs laying around from my thesis and they give the
results I put in it. Seems to perhaps be a mistake from me that the TNTC
enabled runs weren't optimal due to some background process I didn't
notice. Also there were some nofib programs I didn't include at that
time due to problems getting them running, the missing ones seems to
have reduced the advantage of TNTC.
> I have to admit, the results I'm getting are what I would expect, so its
> conceivable that some subconscious experimental bias has crept in
> somewhere :-)
Actually its more of an unconscious self sabotage. When I did the
benchmarking of TNTC I was hoping to get the 4-6% value that I had seen
talked of before since that's basically the margin by which the LLVM
back-end is slower then the NCG. I think my body was punishing me from
lack of sleep :).
> [snip/new email]
> So here's a crazy idea. Why don't we post-process the assembly code
> coming out of LLVM? Before you throw up your hands in horror, consider that
I think it should work pretty well, especially if its intentioned to
just be a stopgap solution until we get support for TNTC from LLVM.
More information about the Cvs-ghc