Native Code Generator for AArch64

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Native Code Generator for AArch64

Moritz Angermann-2
Hi there!

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.

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. 

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.

I have performed nofib benchmarks for:
- full llvm build vs full native build[4]
- llvm nofib, with native libraries, vs full native build[5]
to discriminate effects of compiling just the nofib programs vs. the impact the libraries have.

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.

I plan to look at aarch64/mach-o and performance over the coming weeks.

I hope we can get this in for 9.2.

Cheers,
 Moritz

--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Native Code Generator for AArch64

Takenobu Tani
Steady and wonderful work!


Regards,
Takenobu

On Sat, Sep 26, 2020 at 6:44 PM Moritz Angermann
<[hidden email]> wrote:

>
> Hi there!
>
> 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.
>
> 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.
>
> 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.
>
> I have performed nofib benchmarks for:
> - full llvm build vs full native build[4]
> - llvm nofib, with native libraries, vs full native build[5]
> to discriminate effects of compiling just the nofib programs vs. the impact the libraries have.
>
> 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.
>
> I plan to look at aarch64/mach-o and performance over the coming weeks.
>
> I hope we can get this in for 9.2.
>
> Cheers,
>  Moritz
>
> --
> [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
> [3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068
> [5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Native Code Generator for AArch64

Shayne Fletcher
In reply to this post by Moritz Angermann-2
Outstanding!

On Sat, Sep 26, 2020, 05:43 Moritz Angermann <[hidden email]> wrote:
Hi there!

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.

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. 

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.

I have performed nofib benchmarks for:
- full llvm build vs full native build[4]
- llvm nofib, with native libraries, vs full native build[5]
to discriminate effects of compiling just the nofib programs vs. the impact the libraries have.

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.

I plan to look at aarch64/mach-o and performance over the coming weeks.

I hope we can get this in for 9.2.

Cheers,
 Moritz

--
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs