Removing/deprecating -fvia-c at at
Tue Feb 16 22:26:08 EST 2010

It seems to me, in the absence of any other fallback, that the C backend should stay around. Assume that one is porting to a new platform, the C backend at least gives one code from which to bootstrap.

Calling convention handling: weak argument IMHO for ditching. Sounds like refactoring is required, and, yes, it's platform-specific.

Perl script postprocessing foo: I haven't looked at the code, but again, it sounds like platform-specific refactoring. Yes, I've looked at the web page.

There's a reason why backends are messy goo and have target triples, etc. It's like Monad: not everything is pure.

My vote is to keep the C backend. If it's good enough for LLVM, it's probably good enough for GHC.

------Original Message------
From: Don Stewart
Sender: glasgow-haskell-users-bounces at
To: glasgow-haskell-users at
Subject: Re: Removing/deprecating -fvia-c
Sent: Feb 14, 2010 09:58

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

-- Don
Glasgow-haskell-users mailing list
Glasgow-haskell-users at

Sent from my Verizon Wireless BlackBerry

More information about the Glasgow-haskell-users mailing list