LLVM doesn't ever even bother with rewrite rules. That's done substantially earlier in the compiler, at the Core phase (rewrite rules are 'just' equational reasoning optimizations that the compiler is aware of, so it works roughly at the level of the program you write, vs any more complicated intermediate form.)

There is still some inlining/smarts going on at the LLVM level, obviously, but it's nowhere near as aggressive as it is at the Core level in GHC. And obviously rewrite rules are user-definable - so they kick in much earlier. (As a side note, we actually spit out pretty optimized LLVM code from the C-- backend, in such a way that only some of LLVM's heaviest optimizations make a difference).

There are some specific optimizations that are simply not possible for LLVM in the general case and are better handled before conversion (for example, C-- at one point essentially gets CPS transformed in a way which LLVM cannot 'see through', and by that point you've lost the opportunity to do a number of simpler optimizations like basic constant propagation, while it's trivial to do earlier). But that's mostly the same in any compiler, and not unique to GHC...

Please read the link I provided and search the page for "Problems with the backend"

...There is one major issue remaining with the LLVM backend that I currently know of, its inability to implement a optimisation used by GHC called 'TABLES_NEXT_TO_CODE' (TNTC)...

That was fixed in LLVM 3.6 in a more general way, by one of my coworkers, Ben. http://reviews.llvm.org/D6454

The prologue support directly subsumes previous behavior (the `prefix` form) and is more flexible, and with it, GHC doesn't have to rely on shuffling assembly output in order to achieve TNTC.