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