That was one of my questions in the optimization and rewrite rules thread: shouldn't -fvia-C be supported (as a non-default option) for at least as long as the alternative isn't a clear win in all cases?
The trouble with supporting multiple backends is that the cost in terms of testing and maintenance is high. And the registerised -fvia-C backend is particularly nasty, coming as it does with thousands of lines of Perl 4 that regularly get broken by new versions of gcc.
Yes, I can understand that you'd like to leave that part behind sometime before yesterday:-) I assume that this very complexity means that the -fvia-C route doesn't really get all the way to its most interesting promises (easy portability, and full backend optimizations inherited from gcc). And with that in mind, I can also understand that you don't want to put in any further work into trying to improve it, if that distracts from a better long-term solution. What I don't understand yet is the routemap for replacing -fvia-C. We've seen -fvia-C being demoted from default to backup (fine by me), we've seen a feature supported only by -fvia-C removed completely, instead of seeing support for it added to the -fasm route (macro-based APIs used to work with ffi, would now require a wrapper generator, which doesn't exist yet). Indications are that -fvia-C still tends to produce better code (even though it is not the best that ghc+gcc could produce) than -fasm (is that any better for the new backend?). And last, but not least, ghc has more limited resources than gcc, so how is ghc going to beat gcc at the portability and backend optimizations game while still making progress in its core competencies (ie, higher-level improvements; there's also the interesting side-issue of how the two stages of optimizations are going to interact in ghc, if there is a barrier that can only be crossed in one direction)?
The registerised via-C backend should have been retired long ago. It's time to take it round back and shoot it. We should spend our efforts on finding a good long-term solution rather than patching this dead-end, IMHO.
No disagreement there (apart from the violent metaphor). I'm just worried about pragmatics, ie scuttling the ship before we've counted our life boats!-) And I suspect that for ghc trying to do everything itself on all platforms (rather than trying for very good -fasm on some platforms of interest, and good -fvia-C as a fallback everywhere else) is going to be anything but more work than patching that dead-end (though no doubt more interesting). In other words, what is the plan wrt to backends, especially wrt recovering the optimizations and portability issues previously left to gcc? When will the fast via-C route be retired, what quality of replacement will be in place at that time, how long to catch up to where we are now, how to keep up, etc.? Claus