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

Before the "Pile on Scooter" fest starts, bear in mind that LLVM effectively restricts you to its current backends. As the guy who started CellSPU in LLVM and who needs a good couple of research months off to finish it, think this through. Carefully.

FWIW: I lead a computer systems research department for a non-for-profit in real life.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: at
Date: Wed, 17 Feb 2010 03:26:08 
To: Don Stewart<dons at>; <glasgow-haskell-users at>
Subject: Re: Removing/deprecating -fvia-c

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