1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Apple, LLVM Developers Figure Out Their 64-Bit ARM Approach

Compiler

Published on 14 April 2014 09:33 PM EDT
Written by Michael Larabel in Compiler
2 Comments

Two weeks ago Apple open-sourced their 64-bit ARM back-end to LLVM. Following last week's EuroLLVM meeting, they have decided that the community's existing open-source 64-bit ARM back-end will likely be merged into Apple's now-public back-end.

At the "EuroLLVM" meeting last week in Edinburgh, Scotland, developers met to figure out the approach of ARM 64-bit support within LLVM/Clang now that Apple has open-sourced their code-base while various other organizations and community developers have focused on their own 64-bit ARM back-end. Both sides have agreed that the code-bases are to be merged, but the main plan was figuring out the most reasonable approach for combining the two code-bases.

Last week's meeting reaffirmed that the ARM64 back-end is the merge target. The "ARM64" back-end is Apple's back-end while the "AArch64" back-end is the existing 64-bit ARM code. Developers will be working to merge the extra functionality of the existing back-end into the newly open-sourced back-end as soon as possible to avoid code fragmentation and problems. This merging of the two 64-bit ARM back-ends might not happen before the LLVM 3.5 release this summer, but when it does the ARM64 (Apple) back-end will be renamed to AArch64 for ARM's correct naming scheme.

When the two code-bases are complete, no significant regressions can be found from code correctness to features to stability and performance. For those wishing to learn more about the ongoing 64-bit ARM LLVM work can be discovered via this mailing list thread.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. Fedora 21 Beta & Final Release Slip Further
  2. Mesa 10.3.2 Has A Couple Bug-Fixes
  3. RadeonSI/R600g HyperZ Support Gets Turned Back On
  4. openSUSE Factory & Tumbleweed Are Merging
  5. More Fedora Delays: Fedora 21 Beta Slips
  6. Mono Brings C# To The Unreal Engine 4
  7. Coreboot Now Has Support For Intel Broadwell Hardware
  8. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  9. GTK+ Lands Experimental Backend For Mir Display Server
  10. Ubuntu 14.10 Officially Released
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  4. Linux hacker compares Solaris kernel code:
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed