Removing/deprecating -fvia-c

[Don Stewart]

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.

scooter.phd:
> 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: scooter.phd at gmail.com
> Date: Wed, 17 Feb 2010 03:26:08 
> To: Don Stewart<dons at galois.com>; <glasgow-haskell-users at haskell.org>
> 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 haskell.org
> To: glasgow-haskell-users at haskell.org
> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 
> Sent from my Verizon Wireless BlackBerry
>