[LLVMdev] Proposal: AArch64/ARM64 merge from EuroLLVM

Tim Northover t.p.northover at gmail.com
Tue Apr 8 00:03:55 PDT 2014


Hi again,

In my original message I was attempting to summarise the key arguments
as I saw them. Other points came up in the discussion, which Ana
kindly recorded and I'll summarise here:

First, extra arguments brought up in favour of each backend (I'll
mention duplicates too so that the list is as complete as possible):

+ Register class usage in ARM64 is cleaner.
+ FastISel is on ARM64, but not AArch64. Some TableGen work will be
needed to enable it because of how patterns are written there.
+ There is no macro support in AArch64.
+ Both NEON syntax variants (general & iOS) are supported by ARM64 now.
+ ARM64 assumes neon enabled by default, and indeed has no notion that
a CPU might not have NEON. Instructions will need to be predicated to
check NEON is present and probably some corresponding .cpp changes
where it was also assumed.
+ Inline asm is possibly better in ARM64.
+ Anecdotal evidence suggests it's easier to debug MC layer issues on
ARM64 than on AArch64.

Other important points that we discussed:

+ We need to setup a buildbot for performance using some real hardware
(volunteers with hardware?) so patches can be validated in the
supported targets. And also for correctness using qemu.

+ Google is working on a framework to build and run benchmarks – to be
available soon? And should enable the buildbot setup from item above.

+ We need to sort out differences between cortex-a53 and Cyclone model
descriptions (both use the new approach for MI scheduler, but one
requires annotating instructions and the other does not). We should
pin down Andy and get him to describe the perfect machine model.

Cheers.

Tim




More information about the llvm-dev mailing list