Removing/deprecating -fvia-c

[Isaac Dupree]

On 02/16/10 20:13, Roman Leshchinskiy wrote:
> On 15/02/2010, at 04:58, Don Stewart wrote:
>
>> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops?
>
> FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C is a dead end wrt numeric performance because gcc just doesn't optimise well enough. So even if we generated code that gcc could optimise properly (which we don't atm), we still would be way behind highly optimising compilers like Intel's or Sun's. IMO, the LLVM backend is the way to go here.

LLVM and GCC are open-source projects that are improving over time... is 
there any particular reason we expect GCC to have poor numeric 
performance forever?

[now I rehash why to remove -fvia-C anyway. Feel free to ignore me.]

...However, we think the native-code backends (and perhaps LLVM) will be 
good enough within the next few years to catch up with registerized 
via-C; and as soon as they do, it'll be an advantage to remove -fvia-C 
so that we're not restricted by C's calling conventions and other such 
restrictions.  And it's much easier to predict GCC's path for just the 
next two years (for example).  Actually, even if GCC somehow becomes the 
premier optimizer that we'll never be able to replicate with our own 
feeble efforts, it still may not be worth keeping/using/maintaining the 
current perl hacks for that purpose (combining the effort needed to 
maintain them over the time until then, and the effort needed to adapt 
these hacks to C with loops that let GCC optimize better... er, it 
probably won't be *that much* better except in things simple enough that 
it's easier to add optimizations inside GHC than to maintain this 
backend anyway).

scooter.phd wrote:
> Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully.

Currently we have
- "unregisterized", using GCC. This is the most portable, fairly 
reliable, and will stay.
- "registerized" (fvia-C), using GCC. This tends to break (e.g. 
registerized PowerPC is broken)
- -fasm (native code generator). This can break from refactoring in GHC 
but not from new versions of GCC, so it is less annoying than the 
-fvia-C path.
And we'll hopefully have
- LLVM backend, with (currently) fewer supported architectures than GCC 
but more than GHC's native-codegens.

If you finish your CellSPU work, great! GHC 6.16 or so might be able to 
perform well on CellSPU! If not, then the present situation of using the 
"unregisterized" (slow) C backend will still be available; we don't lose 
much by removing the few current "registerized" backends. (Actually it's 
likely to require some build-system fixes in porting to any new 
platform, even with the unregisterized backend.)  (Also, if it turns out 
to be easier to make a GHC native-code generator backend than an LLVM 
backend, then maybe that will be yet another theoretical possibility!)

-Isaac