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