Android mandates that devices have at least vfpv3-d16 until
Marshmallow and NEON after that. Still honor the user's decision, but
raise the defaults for Android targets.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
Related to this but something I was less sure we should do: Android no longer supports ARMv5. Should we make arm-linux-androideabi targets auto pull up to armv7 if there's no -march flag?
Seems fine to me too. I'd maybe just add an additional test case to verify that things still work as expected when users explicitly specify that they want to target a different FPU (e.g. "-mfpu=none").
It looks like we might be able to simplify a bit, and I think there probably could be some more test cases but no objections from me.
lib/Driver/ToolChains/Arch/ARM.cpp | ||
---|---|---|
360 | Do you need to parse the arch version here? I would expect the -march=armv7 to be reflected in getARMSubArchVersionNumber(Triple) If reduce this to ArchVersion = getARMSubArchVersionNumber(Triple) and add a test with -target arm-linux-androideabi21 -march=armv7 then everything still passes. If I'm right you should be able to simplify this and perhaps roll it into the if (Triple.isAndroid() && ArchVersion >= 7) below. If I'm wrong can we add a test case that fails without the ArchVersion = llvm::ARM::parseArchVersion(ArchName) ? It will also be worth adding tests for a generic target with -march |
lib/Driver/ToolChains/Arch/ARM.cpp | ||
---|---|---|
360 | I had assumed that that wouldn't handle a case like -target arm-linux-androideabi21 -march=armv7-a where the -target argument specifies ARMv5 but -march rasies that to ARMv7, but you're right, the triple is updated to account for -march (which makes sense now that I think about it; that would lead to a lot of messy code all over if it didn't). Cleaned this up. (I think I've also added the test you're asking for, but lmk if I misunderstood what you meant by "generic target") | |
test/Driver/arm-mfpu.c | ||
410 | Is this test (and it's counterpart in CHECK-ARM-ANDROID-L-FP-NEON) not sufficient? It shows that -mfpu is honored regardless of the default. Is there something special about -mfpu=none that this doesn't exercise? |
test/Driver/arm-mfpu.c | ||
---|---|---|
410 | you're right - this test does what I was asking for. Apologies, I should've looked more closely - I hadn't picked up this mfpu isn't the default one... |
Looks good to me. By generic target I just meant --target=arm-linux-androideabi21 with a -march to specify the revision, which you've got in the test.
Do you need to parse the arch version here? I would expect the -march=armv7 to be reflected in getARMSubArchVersionNumber(Triple)
If reduce this to ArchVersion = getARMSubArchVersionNumber(Triple) and add a test with -target arm-linux-androideabi21 -march=armv7 then everything still passes.
If I'm right you should be able to simplify this and perhaps roll it into the if (Triple.isAndroid() && ArchVersion >= 7) below. If I'm wrong can we add a test case that fails without the ArchVersion = llvm::ARM::parseArchVersion(ArchName) ?
It will also be worth adding tests for a generic target with -march