Loop unrolling + fusion ?

[Claus Reinke]

>> 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