The LLVM 64-bit ARM64/AArch64 Back-Ends Have Merged

The LLVM 64-bit ARM64/AArch64 Back-Ends Have Merged(phoronix.com)

41 points by chilledheart 12 years ago | 10 comments

asb 12 years ago |

This has all happened impressively quickly. Apple released their ARM64 implementation at the end of March (http://article.gmane.org/gmane.comp.compilers.llvm.devel/716...). Whether to merge the existing AArch64 in to ARM64 or vise versa was discussed and decided the following week (http://article.gmane.org/gmane.comp.compilers.llvm.devel/717...), and a good portion of the work was done by the end of April (http://article.gmane.org/gmane.comp.compilers.llvm.cvs/18538...). The resulting backend (now named AArch64) contains the best of both AArch64 and Apple's ARM64. A lot of this merging work has been driven by ARM Ltd. itself, who of course as of version 6 build their official compiler on LLVM+Clang (http://www.arm.com/about/newsroom/arm-compiler-builds-on-ope...).

If you're interesting in LLVM/Clang news and developments, you may be interested to subscribe to my http://llvmweekly.org (and/or follow @llvmweekly)

nullc 12 years ago | |

> This has all happened impressively quickly.

I'm confused by this claim. Apple has an ARM64 device shipped to millions of people since September 2013.

It appears to me that they kept their compiler improvements a secret for an additional six months after the public release of a product using them, and so the fact that it's only taken an additional couple months to complete the contribution doesn't really strike me as fast.

What am I missing here?

cokernel_hacker 12 years ago | | |

Merging two compiler backends, despite both targeting the same architecture, is not a day in the park.

LLVM gives you several opportunities to make decisions on how lowering from LLVM IR to machine code will occur, it is not likely that both backends would have been able to handle the same sets of preconditions for each other.

A very obvious example to consider: relocations.

Relocations are tied very closely to the final object file format. I doubt Apple's ARM64 backend had any provisions to deal with the ELF relocations in the psABI and I similarly doubt that the AArch64 backend had any understanding on what kind of relocations were available to it if it were to target Mach-O.

ytch 12 years ago | | |

Apple can actually do this theoretically since LLVM uses "University of Illinois/NCSA Open Source License" [1].

This license is much like BSD License, which doesn't require to release modification.

For Example, Sony uses LLVM as part of the PS4 Toolchain[2], but they also doesn't release their code.

[1] http://llvm.org/releases/2.8/LICENSE.TXT [2] http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain....

pohl 12 years ago | |

Thank you, Alex, for the excellent digest service.

bjackman 12 years ago |

Aside: ARMv8 has made the messy ARM terminology even worse! Quick summary:

ARMv8 (version 8 of the ARM architecture) has two execution states. AARCH64 is the 64-bit mode and AARCH32 is the 32-bit mode. These two modes use two different instruction sets, A64 and A32 respectively (and T32 which is Thumb). A32 is (sort of) compatible with ARMv7 (which is the archiecture version introduced with the Cortex cores).

You will see A64 erroneously used to refer to AARCH64 and ARMv8. You will see AARCH32 erroneously used to refer to ARMv7. You will probably find errors in this post. ARM64 (which is what Linux calls it) seems to just mean "that whole 64 bit malarkey".

And finally, the ARMv8 cores are the Cortex-A53 and -A57 (all the ARMv7 cores are Cortex-An where n is a single digit).

GOT IT?

derefr 12 years ago |

However many arguments there are for the value of standards bodies, this is an impressive example of what happens when stewardship of a technology is in the hands of a company with a monetary incentivize to keep quality high and get changes agreed-upon quickly.