Removing/deprecating -fvia-c

Don Stewart dons at
Wed Feb 17 02:28:29 EST 2010

That's a good perspective, Scooter.

Let's not mythologize LLVM.

Note that Simon's proposing to keep the unregisterized C backend for
bootstrapping, but to avoid further work on the optimizing C backend
(GCC + tailcalls + the evil mangler + lots of register hacks).

The question is whether the current native codegen, plus the
unregistered C "bootstrap backend" is enough for everyone -- and it may
well be, esp. if work will proceed on a new native codegen.
> 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.
> -scooter
> ------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
> 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?
> -- 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