Removing/deprecating -fvia-c

[Simon Marlow]

On 14/02/2010 17:58, Don Stewart wrote:
> igloo:
>>
>> Hi all,
>>
>> We are planning to remove the -fvia-c way of compiling code
>> (unregisterised compilers will continue to compile via C only, but
>> registerised compilers will only use the native code generator).
>> We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in
>> 6.16.
>>
>> Simon Marlow has recently fixed FP performance for modern x86 chips in
>> the native code generator in the HEAD. That was the last reason we know
>> of to prefer via-C to the native code generators. But before we start
>> the removal process, does anyone know of any other problems with the
>> native code generators that need to be fixed first?
>>
>
> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops?
>
> As recently as last year -fvia-C -optc-O3 was still useful for some
> microbenchmarks -- what's changed in that time, or is expected to change?

If you have benchmarks that show a significant difference, I'd be 
interested to see them.

What I've done for 6.14.1 is to add the -msse2 flag to the x86 backend, 
so where previously we had to use -fvia-C -fexcess-precision -optc-O3 
etc. to get reasonable floating point performance, now we can use -msse2 
with the native code gen and get about the same results.

In the future we have a couple of ways that things could get better:

  1. The new back-end, which eventually will incorporate more
     optimisations at the C-- level, and potentially could produce
     good loop code.  It will also free up some registers.

  2. Compiling via LLVM.

Dropping the C backend will give us more flexibility with calling 
conventions, letting us use more of the x86 registers for passing 
arguments.  We can only make this change by removing -fvia-C, though. 
There's low hanging fruit here particularly for the x86 backend, as soon 
as we drop -fvia-C.

There are other reasons to want to get rid of -fvia-C:

  - it doubles the testing surface

  - it's associated with a bucketload of grotesque Perl 4 code and
    gcc-specific hacks in the RTS headers.

Cheers,
	Simon