The moment you start trying to compete against hand written assembly, any high level lang gets a bit quirky. One nice thing about ghc Haskell is you can though! A lot of my own open source work is towards a vision of making that much easier than it is today :-)
its a very thoughtful, informative, thread. enjoy!
Yes, which is why I wonder why GHC went with it's own code generator instead of using LLVM? It seems like a lot of the outputted assembly would be coalesced with LLVM's optimizer passes. Is there work on this problem within the Haskell world?
This backend (usually coupled with -O2) tends to slow down compile times tremendously, but can make some math-heavy programs much faster.
LLVM didn't exist when GHC was started.
If you read the blog post, you'll see Neil mentions " tried the LLVM backend, but it generated significantly worse assembly code https://github.com/ndmitchell/blogs/blob/master/inner-loop/I...
@tenslsi : theres certainly room for improving llvm, the ghc native code gen, and pretty much any compiler generally (ghc is no different). I'm actively involved in GHC dev, and i've somewhat committed to spending some volunteer time this year improving the NCG and various backend optimization tooling.
anyways, the reddit discussion of the blog post is also pretty interesting
It's worth noting the LLVM version Neil tried was 2.8, from Dec 2010. LLVM has come a long way since then and I'd be surprised to see if produce such horrible code. I'm hoping Neil will do an updated post using LLVM 3.4 released last week.
http://blog.omega-prime.co.uk/?p=135
Quote: "In particular, LLVM conservatively assumes that GHC's stack and the heap may alias". LLVM has to assume that short of Haskell-specific analysis, so updating to LLVM 3.4 won't help with such issues.