[LLVMdev] Proposal: AArch64/ARM64 merge from EuroLLVM

[Tim Northover]

Hi again,

Having heard no howls of protest, those of us remaining on the
Wednesday decided to get down to planning a few more details of the
merge.

David Kipping very kindly took notes, and we've produced the summary
of the discussion below:

On Wednesday after the EuroLLVM meeting, a group met to continue
discussing the ARMv8 backend merge and how to accelerate completion.
Attending was James, Bradley, Tim, Jiangning, Kristof, Vinod,
Chandler, Pierre, Ana, and David.

EuroLLVM provided a timely and convenient opportunity to meet in
person to discuss this topic. But it is important to note that this is
only one meeting and some issues likely have been missed, and that not
everyone involved in the discussion was at EuroLLVM; everything below
is open for further discussion and revision on the community lists.

Later in the mail are details on the work to complete the merge, but
there is a lot and participation from the community is warmly welcome.
This is an excellent opportunity if you want to learn more about
backends, the ARMv8 architecture, or just want to ensure that the
community ARMv8 backend is of this highest quality and performance.
Some of the areas that have been identified needing help are:

- Code reviews (there will be lots of changes and quality of review
and timeliness is critical)
- Merging regression tests from both ARMv8 backends - Tim will lead
this effort but is looking for help
- Inline ASM (I think Eric said at the Hackers Lab that he might be
willing to do this)
- Fix bugs
- For others who want to help test, compiling and running your
codebases on QEMU (no crypto extensions)
- Code coverage analysis of backend
- Clean up the codebase (C++11-ify it, for example) -  J im will lead
this effort
- In addition, any of the work items identified later in this mail

-----------------------------------------------------------------------------------------------------------------

Summary of the meeting:

The meeting reaffirmed the conclusion of the discussion at the
EuroLLVM Hackerlab of using ARM64 backend as the merge target.

It's important to merge as quickly as possible to avoid fragmentation
of community efforts across two backends . Completing the merge in
time for the 3.5 release shall be a stretch goal, but this will be
very difficult because of the short time remaining, and may be missed.
More important than schedule, is to make sure the merge is done right
with good design that is maintainable.

When the merge is complete, need to delete AArch64 and rename ARM64 to
AArch64 to avoid confusion. Also, alias together the arm64 and aarch64
triples to the merged backend.

Should try to minimize patches to AArch64 during the merge, but it is
important to realize that this backend is being used for product
releases and there are contributions in flight and more expected. Bugs
should be filled for ARM64 when appropriate.

Work that needs to be completed prior to the merge is considered complete:

- No significant regressions: correctness, features, stability,
performance. There will likely be exceptions, particularly in some
performance subtests, that need to be addressed on a case by case
basis

- Correctness
-- Merged backend passes LLVM test suite
-- Merged backend passes the invested parties internal tests (Apple,
ARM, QuIC) and should not have significant regressions. It should be
recognized that this is a special situation as there are commercial
releases being made on the two backends, and for adoption of the merge
it is critical that there are no regressions. Examples of tests are:
SPEC2000, SPEC2006, EEMBC, Geekbench, Coremark, MCHammer, Emperor
(NEON)

- Performance - Difficult to have precise and fixed baseline for
measuring performance regressions on the merged backends because of
variability in hardware, but all significant performance regressions
must be investigated and justified as fix/notfix

- Feature parity - to the level found in the ARM64 and AArch64 backends today
-- big-endian
-- Optionality of ARMv8 architecture extension sets (no fpu, crypto, crc, ...)
-- A53 scheduler
-- Inline assembly
-- ACLE 2.0
--- Neon (chapter 12 of ACLE); probably there already on the ARM64 backend
--- Predefines
-- Proper guarding of platform-specific features (Cyclone, Darwin, ELF, …)
-- Regression tests from both backends merged

The following patches were identified in order to swap in the merged
backend once the merge is completed:

- Delete AArch64 backend
- Move and rename ARM64 to AArch64 (Changes filename, class names,
replace all non comments ARM64 strings to AArch64)
- Retarget ARM64 triples to merged backend
- Clean up any ARM64 references elsewhere in llvm subprojects

The following is the anticipated sequence of work leading to a merge:

- During merge, invested parties will frequently run their internal
correctness, stability and performance tests. Report bugs as
appropriate (ALL)
- System registers redesign, refactoring to use some more of tablegen
resources, and bug fixes (45 patches from ARM were reviewed during the
meeting)
- A53 scheduler - (Dave E, Ana, Andy) have already started discussing
- LLVM test suite run and report failures (Jiangning/Kevin/Hao)
- LLVM test suite enabled in the buildbot and testing ARM64 (Gabor)
- CSE of ADRP optimization (Jiangning)
- Making optional armv8 architecture extension sets optional in LLVM;
no fpu, crypto, crc, ... (Jiangning/Kevin/Hao)
- Proper guarding of platform-specific features (Cyclone, Darwin, ELF, …) (Tim)
- Big-endian (James/Bradley/Kristof)
- Predefines (Bradley)
- Fixes bugs (ALL)
- Backend switch patch-sets (Tim)

Communication during the merge
- Primary discussions will take place on llvmdev, llvm-commits, and IRC
- A top-level bug: http://llvm.org/bugs/show_bug.cgi?id=19392
- Depending on how things go, we may want to get together for some
kind of telephone call. We'll send a message to the list if that
happens.

I think that about covers it. If anyone has any questions, ask away!

Cheers.

Tim.