<div dir="ltr">Austin also raises an important point: <div><br><div>Its high time we explore changes to the ABI/per architecture calling convention and how they might impact performance.</div><div><br></div><div> I think this is something worth exploring after the 7.8 release </div>
<div>(but not in the next month of prerelease engineering, though I need to suss out some of that a bit more with the parties who care)</div><div><br></div><div>I had started working on a backwards compatible ABI change for llvm a few months back that I could easily get LLVM folks to merge in, but I'd rather only give the LLVM folks 1 set of ABI change patches within a 6month period, where we've had the time to experiment with breaking changes as an option too, rather than given them a partial patch now, and then a breaking changes calling convention patch a few months from now.</div>
<div><br></div><div>(because if we don't bundle LLVM with GHC, we need to actually tie ABI versions to LLVM major version releases, which isn't a problem, but just requires thoughtful cooperation and such)</div><div>
<br></div><div>cheers<br><div style>-Carter</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 12:51 PM, Austin Seipp <span dir="ltr"><<a href="mailto:aseipp@pobox.com" target="_blank">aseipp@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To do this, IMO we'd also really have to start shipping our own copy<br>
of LLVM. The current situation (use what we have configured or in<br>
$PATH) won't really become feasible later on.<br>
<br>
On platforms like ARM where there is no NCG, the mismatches can become<br>
super painful, and it makes depending on certain features of the IR or<br>
compiler toolchain (like an advanced, ISA-aware vectorizer in LLVM<br>
3.3+) way more difficult, aside from being a management nightmare.<br>
<br>
Fixing it does require taking a hit on things like build times,<br>
though. Or we could use binary releases, but we occasionally may want<br>
to tweak and/or fix things. If we ship our own LLVM for example, it's<br>
reasonable to assume sometime in the future we'll want to change the<br>
ABI during a release.<br>
<br>
This does bring other benefits. Max Bolingbroke had an old alias<br>
analysis plugin for LLVM that made a noticeable improvement on certain<br>
kinds of programs, but shipping it against an arbitrary LLVM is<br>
infeasible. Stuff like this could now be possible too.<br>
<br>
In a way, I think there's some merit to having a simple, integrated<br>
code generator that does the correct thing, with a high performance<br>
option as we have now. LLVM is a huge project, and there's definitely<br>
some part of me that thinks this may not lower our complexity budget<br>
as much as we think, only shift parts of it around ('second rate'<br>
platforms like PPC/ARM expose way more bugs in my experience, and<br>
tracking them across such a massive surface area can be quite<br>
difficult.) It's very stable and well tested, but an unequivocal<br>
dependency on hundreds of thousands of lines of deeply complex code is<br>
a big question no matter what.<br>
<br>
But, the current NCG isn't that 'simple correct thing' either, though.<br>
I think it's easily one of the least understood parts of the compiler<br>
with a long history, it's rarely refactored or modified (very unlike<br>
other parts,) and it's maintained only as necessary. Which doesn't<br>
bode well for its future in any case.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Aug 26, 2013 at 3:19 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
> On 26/08/13 08:17, Ben Lippmeier wrote:<br>
>><br>
>><br>
>>> > Well, what's the long term plan? Is the LLVM backend going to<br>
>>> become the only backend at some point?<br>
>>><br>
>>> I wouldn't argue against ditching the NCG entirely. It's hard to<br>
>>> justify fixing NCG performance problems when fixing them won't<br>
>>> make the NCG faster than LLVM, and everyone uses LLVM anyway.<br>
>>><br>
>>> We're going to need more and more SIMD support when processors<br>
>>> supporting the Larrabee New Instructions (LRBni) appear on<br>
>>> people's desks. At that time there still won't be a good enough<br>
>>> reason to implement those instructions in the NCG.<br>
>>><br>
>>> I hope to implement SIMD support for the native code gen soon. It's<br>
>>> not a huge task and having feature parity between LLVM and NCG would<br>
>>> be good.<br>
>><br>
>><br>
>> Will you also update the SIMD support, register allocators, and calling<br>
>> conventions in 2015 when AVX-512 lands on the desktop? On all supported<br>
>> platforms? What about support for the x86 vcompress and vexpand<br>
>> instructions with mask registers? What about when someone finally asks<br>
>> for packed conversions between 16xWord8s and 16xFloat32s where you need<br>
>> to split the result into four separate registers? LLVM does that<br>
>> automatically.<br>
>><br>
>> I've been down this path before. In 2007 I implemented a separate graph<br>
>> colouring register allocator in the NCG to supposably improve GHC's<br>
>> numeric performance, but the LLVM backend subsumed that work and now<br>
>> having two separate register allocators is more of a maintenance burden<br>
>> than a help to anyone. At the time, LLVM was just becoming well known,<br>
>> so it wasn't obvious that implementing a new register allocator was a<br>
>> largely a redundant piece of work -- but I think it's clear now. I was<br>
>> happy to work on the project at the time, and I learned a lot from it,<br>
>> but when starting new projects now I also try to imagine the system that<br>
>> will replace the one I'm dreaming of.<br>
>><br>
>> Of course, you should do what interests you -- I'm just pointing out a<br>
>> strategic consideration.<br>
><br>
><br>
> The existence of LLVM is definitely an argument not to put any more effort<br>
> into backend optimisation in GHC, at least for those optimisations that LLVM<br>
> can already do.<br>
><br>
> But as for whether the NCG is needed at all - there are a few ways that the<br>
> LLVM backend needs to be improved before it can be considered to be a<br>
> complete replacement for the NCG:<br>
><br>
> 1. Compilation speed. LLVM approximately doubles compilation time. Avoiding<br>
> going via the textual intermediate syntax would probably help here.<br>
><br>
> 2. Shared library support (#4210, #5786). It works (or worked?) on a couple<br>
> of platforms. But even on those platforms it generated worse code than the<br>
> NCG due to using dynamic references for *all* symbols, whereas the NCG knows<br>
> which symbols live in a separate package and need to use dynamic references.<br>
><br>
> 3. Some low-level optimisation problems (#4308, #5567). The LLVM backend<br>
> generates bad code for certain critical bits of the runtime, perhaps due to<br>
> lack of good aliasing information. This hasn't been revisited in the light<br>
> of the new codegen, so perhaps it's better now.<br>
><br>
> Someone should benchmark the LLVM backend against the NCG with new codegen<br>
> in GHC 7.8. It's possible that the new codegen is getting a slight boost<br>
> because it doesn't have to split up proc points, so it can do better code<br>
> generation for let-no-escapes. (It's also possible that LLVM is being<br>
> penalised a bit for the same reason - I spent more time peering at<br>
> NCG-generated code than LLVM-generated code).<br>
><br>
> These are some good places to start if you want to see GHC drop the NCG.<br>
><br>
> Cheers,<br>
> Simon<br>
><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Austin - PGP: 4096R/0x91384671<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div>