Hi all,
A bunch of us met at EuroLLVM to discuss the planned merge of the two
current AArch64 backends in the tree. The primary question was which
backend should form the basis of the merge (since the core .td files
aren't directly mergeable), with code being cherry-picked from the
other on a case-by-case basis.
There were factors to consider both ways, but I think the key points
of interest were agreed on by everyone:
1. That getting the merge done as quickly as possible was important to
avoid duplicated effort and confusion among our users.
2. That neither performance nor correctness were particularly useful
discriminators between the backends. Both are good enough to form the
basis on those grounds.
Ana Pazos had managed to run some benchmarks on Cortex-A53 (an
in-order CPU) which showed that porting a few simple cases across
could reduce differences to low single digits, with winners in both
directions.
Similarly, people from ARM had managed to resolve most known
correctness issues since the initial commits last week.
That leaves long-term maintenance and features as the remaining
factors to make the decision: we want to spend as little effort as
possible (in total) to do things on the backend, both now and in
future.
In the short term, ARM64 is the clear choice; it simply has more
features now: ELF, FastISel, and the two NEON syntaxes were mentioned.
On the other side there was incipient big-endian and CPUs with
different sub-features (NEON/FP/...).
Longer term, the question is much more difficult. Maintainability is
often a matter of taste and there are issues with both backends (which
we should do our best to resolve!): ARM64 has horrific handling of
aliases and hacks in the various MC components (AsmParser,
Disassembler, ...); AArch64 has similar contortions in the .td files
(see loads/stores & instruction proliferation for aliases). ARM64 has
a clean implementation of calling conventions; AArch64 has its sysreg
lookup. I don't think either has fundamental barriers to a clean
design in future, personally, though AArch64 probably needs a couple
more pushes to get there.
The tentative conclusion was that we probably have all the information
we need available and should propose using the ARM64 backend as the
basis on the list and continue discussion here.
Tim.
