<div dir="auto">Outstanding!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 26, 2020, 05:43 Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi there!<br><div><br></div><div>As some may know I've been working on a native code generation backend for aarch64[1].  When Ben initially wrote about The state of GHC on ARM[2], I was quite skeptical if a native code generator would really be what we should be doing.  And the claim it would take a week or two, might have been underestimating the complexity a bit; but also the time needed to debug crashing programs.</div><div><br></div><div>The idea of a NCG however intrigued me.  I did work on an alternative llvm backend once, so I did know a bit about the code gen backend.  I also knew a bit about aarch64 assembly from working on the rts linker for aarch64. </div><div><br>So here we are today, with an aarch64 ncg for ghc[3], that has some basic optimizations included, but does not beat the llvm codegen yet in runtime performance. It is however substantially faster than the llvm codegen for compile time performance.</div><div><br></div><div>I have performed nofib benchmarks for:<br>- full llvm build vs full native build[4]</div><div>- llvm nofib, with native libraries, vs full native build[5]</div><div>to discriminate effects of compiling just the nofib programs vs. the impact the libraries have.</div><div><br></div><div>I've only had time to take a cursory look over the generated assembly for the CSD test, and the llvm codegen seems to be able to produce quite different assembly, thus there seem to be some good optimizations llvm manages to exploit. I'll have to investigate this closer and probably look at the llvm IR we generate and the intermediate optimization steps llvm manages to apply to it, as the llvm assembly doesn't ressemble the ncg assembly much.</div><div><br></div><div>I plan to look at aarch64/mach-o and performance over the coming weeks.</div><div><br></div><div>I hope we can get this in for 9.2.</div><div><br></div><div>Cheers,</div><div> Moritz</div><div><br></div><div>--</div><div>[1]: <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641" target="_blank" rel="noreferrer">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641</a><br>[2]: <a href="https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html" target="_blank" rel="noreferrer">https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html</a></div><div>[3]: <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641" target="_blank" rel="noreferrer">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641</a><br>[4]: <a href="https://gist.github.com/9d93454b832b769b5bdb4e731a10c068" target="_blank" rel="noreferrer">https://gist.github.com/9d93454b832b769b5bdb4e731a10c068</a><br>[5]: <a href="https://gist.github.com/acc4dab7836f1f509716ac398a94d949" target="_blank" rel="noreferrer">https://gist.github.com/acc4dab7836f1f509716ac398a94d949</a><br></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>