This is an archive of the discontinued LLVM Phabricator instance.

AArch64: add support for newer Apple CPUs
ClosedPublic

Authored by t.p.northover on Nov 27 2019, 5:12 AM.

Details

Reviewers
ab
fhahn
Summary

The CPUs used in Apple devices have been gradually getting more features, but upstream LLVM only knew about the original "Cyclone" variant. Xcode could also target "vortex" (for arm64_32 and arm64e), but using internal names isn't really ideal for anyone.

In official documentation the 64-bit CPUs are known as A7-A13 (iPhone, iPad) and S4-S5 (Watch), with some marketing suffixes that we probably don't need to care about. Since those bare names would be quite a land grab (and easily confused with Cortex-A*), this adds the currently released CPUs as "apple-aN" and "apple-sN".

I've left Cyclone in as a legacy option (build systems and existing bitcode probably relies on it), but switched the default over to the new scheme: apple-a7 for arm64 and apple-s4 for arm64_32.

Diff Detail

Event Timeline

t.p.northover created this revision.Nov 27 2019, 5:12 AM

Test updates after switching arm64_32 default CPU to apple-s4.

I agree the bare names could cause a lot of confusion, and that the naming scheme proposed in this patch resolves that potential confusion.

fhahn accepted this revision.Nov 27 2019, 12:04 PM
fhahn added a subscriber: fhahn.

LGTM, but it might be good to wait with committing until next week, so people in the US have a chance to take a look as well.

clang/lib/Driver/ToolChains/Arch/AArch64.cpp
143

It might be slightly more obvious to use MtuneLowerCAse.StartsWith("apple")

This revision is now accepted and ready to land.Nov 27 2019, 12:04 PM
t.p.northover marked an inline comment as done.Nov 28 2019, 1:25 AM

Thanks Florian. I'll wait as you suggest.

clang/lib/Driver/ToolChains/Arch/AArch64.cpp
143

I'd have preferred to, but unfortnately it's a std::string so doesn't have that function.

kristof.beyls added inline comments.Nov 28 2019, 1:37 AM
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
143
fhahn added inline comments.Nov 28 2019, 1:49 AM
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
143

I'd have preferred to, but unfortnately it's a std::string so doesn't have that function.

Ah yes, that's unfortunate. I somehow assumed it being a StringRef without expanding the context....

ab added inline comments.Dec 2 2019, 12:20 PM
llvm/lib/Target/AArch64/AArch64.td
587

I'm not sure we want to reuse the features:

  • everything will get stuck with FeatureZCZeroingFPWorkaround, right? (but maybe we can remove features in this list? I don't think so)
  • it probably becomes harder to tune later chips, but that's admittedly a theoretical problem at this point
  • some of the features can be generation-specific
t.p.northover marked an inline comment as done.Dec 3 2019, 1:48 AM
t.p.northover added inline comments.
llvm/lib/Target/AArch64/AArch64.td
587

Good points. It's a shame to duplicate everything (and solvable by splitting uArch stuff from the progressive features), but it does seem to be existing practice.

I'll rework it to be more in line with the others and add a test for the workaround you mentioned; that should have been spotted.

Stop inheriting CPU features because they aren't necessarily strictly monotonic.

ab accepted this revision.Dec 3 2019, 10:22 AM

(but either way, LGTM)

llvm/lib/Target/AArch64/AArch64.td
587

Hmm, how about having these in plain top-level tablegen lists? That lets you do (sub), which might be sufficient

ab added inline comments.Dec 3 2019, 10:23 AM
llvm/lib/Target/AArch64/AArch64.td
587

(I don't think that lets us have these cpu "features" though, but TBH I'm not sure what they achieve anyway)

t.p.northover closed this revision.Jan 8 2020, 1:56 AM

Thanks Ahmed, pushed:

To github.com:llvm/llvm-project.git

0a4daff6e26f..903e5c3028d6  master -> master