This is an archive of the discontinued LLVM Phabricator instance.

[ARM][Driver][Windows] Allow command-line upgrade to Armv8.
ClosedPublic

Authored by simon_tatham on Apr 21 2021, 2:47 AM.

Details

Summary

If you gave clang the options --target=arm-pc-windows-msvc and
-march=armv8-a+crypto together, the crypto extension would not be
enabled in the compilation, and you'd see the following warning
message suggesting that the 'armv8-a' had been ignored:

clang: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument]

This happens because Triple::getARMCPUForArch(), for the Win32 OS,
unconditionally returns "cortex-a9" (an Armv7 CPU) regardless of
MArch, which overrides the architecture setting on the command line.

I don't think that the combination of Windows and AArch32 _should_
unconditionally outlaw the use of the crypto extension. MSVC itself
doesn't think so: you can perfectly well compile Thumb crypto code
using its AArch32-targeted compiler.

All the other default CPUs in the same switch statement are
conditional on a particular MArch setting; this is the only one that
returns a particular CPU _regardless_ of MArch. So I've fixed this one
by adding a condition, so that if you ask for an architecture *above*
v7, the default of Cortex-A9 no longer overrides it.

Diff Detail

Event Timeline

simon_tatham created this revision.Apr 21 2021, 2:47 AM
simon_tatham requested review of this revision.Apr 21 2021, 2:47 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 21 2021, 2:47 AM
mstorsjo accepted this revision.Apr 21 2021, 2:50 AM

LGTM, thanks!

clang/test/Driver/woa-crypto.c
3

Nitpick: Is it possible to test this part somewhere using the tools in the llvm subset of the repo? That'd keep the changes a bit more localized?

This revision is now accepted and ready to land.Apr 21 2021, 2:50 AM

Yes, it looks easy enough to add something in llvm/unittests/ADT/TripleTest.cpp to directly test getARMCPUForArch.

I'd mildly prefer to do that as well as having the test here, because the call site in the clang driver is quite complicated. My real aim is that asking for crypto (or any other Armv8-specific extension) should actually get it; I think any accidental regression of that behavior in future is at least as likely to arise from changes in clang/lib/Driver as llvm/lib/Support, so I'd like there to be a test that will detect the regression if it occurs for any reason.

Yes, it looks easy enough to add something in llvm/unittests/ADT/TripleTest.cpp to directly test getARMCPUForArch.

I'd mildly prefer to do that as well as having the test here, because the call site in the clang driver is quite complicated. My real aim is that asking for crypto (or any other Armv8-specific extension) should actually get it; I think any accidental regression of that behavior in future is at least as likely to arise from changes in clang/lib/Driver as llvm/lib/Support, so I'd like there to be a test that will detect the regression if it occurs for any reason.

Fair enough, that sounds like a reasonable plan to me. Yeah having tests for the actual end results is kinda nice instead of just small broken up unit tests, especially when it isn't something that shouldn't change spuriously (like generated code).

Added a unit test on the LLVM side.

mstorsjo accepted this revision.Apr 21 2021, 3:17 AM

Thank you!

This revision was landed with ongoing or failed builds.Apr 21 2021, 3:20 AM
This revision was automatically updated to reflect the committed changes.