Removing/deprecating -fvia-c

[Simon Marlow]

On 17/02/2010 21:15, Scott Michel wrote:

> Depends a lot on the benchmark. The FreeBSD kernel dev crowd (one of
> whom works for me) have seen performance improvements between 10-20%
> using LLVM and clang over gcc. It also depends heavily on which
> optimization passes you have LLVM invoke -- bear in mind that LLVM is a
> compiler optimization infrastructure first and foremost.

Right, such benchmarks tend to be quickly out of date especially when 
both projects are being actively developed.  I have no vested interest 
in either - we'll use whatever suits us better, and that seems to be LLVM.

>     Even so, LLVM doesn't let us generate exactly the code we'd like: we
>     can't use GHC's tables-next-to-code optimisation. Measurements done
>     by David Terei who built the LLVM backend apparently show that this
>     doesn't matter much (~3% slower IIRC), though I'm still surprised
>     that all those extra indirections don't have more of an effect, I
>     think we need to investigate this more closely.  It's important
>     because if the LLVM backend is to be a compile-time option, we have
>     to either drop tables-next-to-code, or wait until LLVM supports
>     generating code in that style.
>
>
> This sounds like an impedance mismatch between GHC's concept of IR and
> LLVM's.

It certainly is an impedence mismatch - there's no good reason why LLVM 
couldn't generate the code we want, but its IR doesn't allow us to 
represent it.  So there's every reason to believe that this could be 
fixed in LLVM without too much difficulty.

We can work around the impedence mismatch the other way, by not using 
tables-next-to-code in GHC, but that costs us a bit in performance.

> [disclaimer: grain of salt speculation, haven't read the code]
> Tables-next-to-code has an obvious cache-friendliness property, BTW.

Oh absolutely, that's why it's not a clear win and some people argue 
that the code cache pollution should outweigh the negative effects of 
those extra indirections. Having seen the effect of branch 
mispredictions though I'm inclined to believe that those indirections 
are more expensive, though.  The cost is this: every return to a stack 
frame takes two indirections rather than one.

Of course GHC's two representations are not the only two you could 
choose - people have been designing clever ways to map code addresses to 
data structures for a long time.  If returning to a stack frame is the 
dominant operation then you would put the return address on the stack 
and use a hash table to map those to info tables.  That trades off 
mutator time against GC time, and we don't know whether it would be a 
win, but we do know it would take a lot of effort to find out.  The 
tables-next-to-code representation means that you don't have to fiddle 
around with hash tables, so it's simpler and probably faster.

> Generally, there's going to be some instruction prefetch into the cache.
> This is likely why it's faster. Otherwise, you have to warm up the data
> cache, since LLVM spills the tables into the target's constant pool.

Not sure what "spills the tables" means, but maybe that's not important.

> NCGs should be faster than plain old C. Trying to produce optimized C is
> the fool's errand, and I'm starting to agree with dropping that. My
> worry was that the C backend would be dropped in its entirety, also a
> fool's errand.

Yes, exactly.

Cheers,
	Simon