marlowsd at gmail.com
Mon Feb 15 11:37:55 EST 2010
On 14/02/2010 17:58, Don Stewart wrote:
>> 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
>> 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.
More information about the Glasgow-haskell-users