Loop unrolling + fusion ?

[Simon Marlow]

Claus Reinke wrote:
>>> its loop unroller on this guy haven't succeeded. -funroll-loops and
>>> -funroll-all-loops doesn't  touch it,
>>
>> That's because the C produced by GHC doesn't look like a loop to GCC.  
>> This can be fixed but given that we are moving away from -fvia-C  
>> anyway, it probably isn't worth doing.
> 
> 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?
> 
> If there are small changes that could make GHC-generated code
> more palatable to GCC's optimizer, wouldn't that be worth doing?
> Once -fvia-C is allowed to bitrot to the level of unoptimized
> bootstraps only, we might never get the good performance route
> back, so why not keep it in good shape as long as it offers real benefits?

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.

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.

Cheers,
	Simon