On 26/08/13 08:17, Ben Lippmeier wrote:
> Well, what's the long term plan? Is the LLVM backend going to
become the only backend at some point?
I wouldn't argue against ditching the NCG entirely. It's hard to
justify fixing NCG performance problems when fixing them won't
make the NCG faster than LLVM, and everyone uses LLVM anyway.
We're going to need more and more SIMD support when processors
supporting the Larrabee New Instructions (LRBni) appear on
people's desks. At that time there still won't be a good enough
reason to implement those instructions in the NCG.
I hope to implement SIMD support for the native code gen soon. It's
not a huge task and having feature parity between LLVM and NCG would
be good.
Will you also update the SIMD support, register allocators, and calling
conventions in 2015 when AVX-512 lands on the desktop? On all supported
platforms? What about support for the x86 vcompress and vexpand
instructions with mask registers? What about when someone finally asks
for packed conversions between 16xWord8s and 16xFloat32s where you need
to split the result into four separate registers? LLVM does that
automatically.
I've been down this path before. In 2007 I implemented a separate graph
colouring register allocator in the NCG to supposably improve GHC's
numeric performance, but the LLVM backend subsumed that work and now
having two separate register allocators is more of a maintenance burden
than a help to anyone. At the time, LLVM was just becoming well known,
so it wasn't obvious that implementing a new register allocator was a
largely a redundant piece of work -- but I think it's clear now. I was
happy to work on the project at the time, and I learned a lot from it,
but when starting new projects now I also try to imagine the system that
will replace the one I'm dreaming of.
Of course, you should do what interests you -- I'm just pointing out a
strategic consideration.
The existence of LLVM is definitely an argument not to put any more
effort into backend optimisation in GHC, at least for those
optimisations that LLVM can already do.
But as for whether the NCG is needed at all - there are a few ways that
the LLVM backend needs to be improved before it can be considered to be
a complete replacement for the NCG:
1. Compilation speed. LLVM approximately doubles compilation time.
Avoiding going via the textual intermediate syntax would probably help here.
2. Shared library support (#4210, #5786). It works (or worked?) on a
couple of platforms. But even on those platforms it generated worse
code than the NCG due to using dynamic references for *all* symbols,
whereas the NCG knows which symbols live in a separate package and need
to use dynamic references.
3. Some low-level optimisation problems (#4308, #5567). The LLVM
backend generates bad code for certain critical bits of the runtime,
perhaps due to lack of good aliasing information. This hasn't been
revisited in the light of the new codegen, so perhaps it's better now.
Someone should benchmark the LLVM backend against the NCG with new
codegen in GHC 7.8. It's possible that the new codegen is getting a
slight boost because it doesn't have to split up proc points, so it can
do better code generation for let-no-escapes. (It's also possible that
LLVM is being penalised a bit for the same reason - I spent more time
peering at NCG-generated code than LLVM-generated code).
These are some good places to start if you want to see GHC drop the NCG.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
