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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
