Removing/deprecating -fvia-c

[scooter.phd at gmail.com]

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