Merge Request: LLVM Code Generator for GHC

[David Terei]

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.

>
> Cheers,
> Simon