Re: Removing/deprecating -fvia-c

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@gmail.com Date: Wed, 17 Feb 2010 03:26:08 To: Don Stewart; 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@haskell.org To: glasgow-haskell-users@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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Sent from my Verizon Wireless BlackBerry