Merge Request: LLVM Code Generator for GHC

[Simon Marlow]

On 25/02/2010 00:08, David Terei wrote:
> 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 :).

Ok, at least that's cleared up.

>  > [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.

Great!

Cheers,
	Simon