The LLVM 64-bit ARM64/AArch64 Back-Ends Have Merged(phoronix.com)
phoronix.com
The LLVM 64-bit ARM64/AArch64 Back-Ends Have Merged
http://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk
3 comments
> 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?
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?
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.
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.
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....
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....
Poll: how many people think this is a bad thing?
Thank you, Alex, for the excellent digest service.
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?
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?
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.
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)