[Driver] Add -print-multi-flags-experimental option

[michaelplatings]

Summary

This option causes the flags used for selecting multilibs to be printed.
This is an experimental feature that is documented in detail in D143587.

[Joe]

So again, I took these patches for a spin with RISC-V. As I mentioned before, I was using a GCC installation, so the multilib selection happens inside Gnu.cpp (findRISCVBareMetalMultilibs). The main trouble I had was at that point we don't have a reference to the ToolChain, so calling getMultiSelectionFlags was not possible. I had a go at making this function static, and it was mostly fine as you could just pass in the Triple and Driver, however getSanitizerArgs was not possible. I'm not sure what the solution here is.

Multilibs for RISCV are straightforward, they just depend arch+abi, so I added the arch extensions and abi to the Result in getMultiSelectionFlags.

With that modified getMultiSelectionFlags, it worked well :)

[michaelplatings]

The main trouble I had was at that point we don't have a reference to the ToolChain, so calling getMultiSelectionFlags was not possible. [...] I'm not sure what the solution here is.

I see two options:

1. Split getMultiSelectionFlags into needs-ToolChain and doesn't-need-ToolChain parts, with the former calling the latter. From Gnu.cpp, call the latter, with the limitation that it can use fewer flags.
2. Pass a ToolChain to the Gnu.cpp functions.

I added the arch extensions and abi to the Result in getMultiSelectionFlags

What was the syntax you used for that?
I'm not super keen on the march=+ext syntax I came up with so I'm open to alternatives.

[Joe]

The main trouble I had was at that point we don't have a reference to the ToolChain, so calling getMultiSelectionFlags was not possible. [...] I'm not sure what the solution here is.

I see two options:

1. Split getMultiSelectionFlags into needs-ToolChain and doesn't-need-ToolChain parts, with the former calling the latter. From Gnu.cpp, call the latter, with the limitation that it can use fewer flags.
2. Pass a ToolChain to the Gnu.cpp functions.

I did briefly try to pass a ToolChain to Gnu.cpp functions, but it became intrusive and had to add it in 5+ places, so unless I'm missing a trick to get the ToolChain from the Driver, my vote would go to the former.

I added the arch extensions and abi to the Result in getMultiSelectionFlags

What was the syntax you used for that?
I'm not super keen on the march=+ext syntax I came up with so I'm open to alternatives.

I dropped the march= and used the same format as target-features, so it was simply +m or +a. I think this is intuitive enough without the march=, and the form x=y is already broken when you add the flags from the flag list. I don't have a strong stance on this though.

[michaelplatings]

In D142933#4099043, @Joe wrote:

I did briefly try to pass a ToolChain to Gnu.cpp functions, but it became intrusive and had to add it in 5+ places, so unless I'm missing a trick to get the ToolChain from the Driver, my vote would go to the former.

The Driver class does in fact have a private getToolChain method. So two new possibilities:

1. Make getToolChain public.
2. Make getMultiSelectionFlags a method of Driver.

I dropped the march= and used the same format as target-features, so it was simply +m or +a. I think this is intuitive enough without the march=

Thanks for explaining. I found that when I was writing a regex to match flags it was helpful to have a part of the string I could be sure would be there to avoid matching the wrong type of flag, and march= helped with that. I also worry that names from different types of flags could clash without some kind of namespacing.

the form x=y is already broken when you add the flags from the flag list.

Can you give an example of what you mean by that? Sounds like something that might need fixing.

[Joe]

Thanks for explaining. I found that when I was writing a regex to match flags it was helpful to have a part of the string I could be sure would be there to avoid matching the wrong type of flag, and march= helped with that. I also worry that names from different types of flags could clash without some kind of namespacing.

Understandable about the flag names clashing. The scope of riscv multilibs was just arch/abi, so there was no concern about clashing/matching the wrong type of flag. Would it be weird for one target to have the march= but anothers not?

clang/lib/Driver/Driver.cpp

2221

Do we want to parse the multilib.yaml here so we can print out custom flags as well? It could help diagnose issues people have with them.

clang/lib/Driver/ToolChain.cpp

206

the form x=y is already broken when you add the flags from the flag list.

Can you give an example of what you mean by that? Sounds like something that might need fixing.

For example the option name for OPT_fexceptions is just fexceptions, and this is added directly to Results

[michaelplatings]

In D142933#4099587, @Joe wrote:

Would it be weird for one target to have the march= but anothers not?

Yes I think it would be weird. Potentially you could have a toolchain supporting Arm and other architectures so it would be unfortunate for that to be inconsistent. I'd very much like the API to work as well as possible across all architectures now, because it's going to be hard to change later. It's great getting your feedback on this.

clang/lib/Driver/Driver.cpp

2221

Yes, I think that would be an improvement. Might need to go in a later patch though.

clang/lib/Driver/ToolChain.cpp

206

OK, I was thrown by the word "broken".
The syntax for the multilib flags is derived from the command line arguments so I think this is fine.

[michaelplatings]

In D142933#4099043, @Joe wrote:

I did briefly try to pass a ToolChain to Gnu.cpp functions, but it became intrusive and had to add it in 5+ places, so unless I'm missing a trick to get the ToolChain from the Driver, my vote would go to the former.

I looked into moving getMultiSelectionFlags into the Driver class but it felt wrong.

I think the place you need to call getMultiSelectionFlags is from findRISCVBareMetalMultilibs and findRISCVMultilibs. They will indeed need changing to take a const ToolChain&. They are called from ScanGCCForMultilibs which is a method of GCCInstallationDetector. GCCInstallationDetector could have a const ToolChain& member. GCCInstallationDetector is only instantiated from the Generic_GCC constructor - Generic_GCC is a subclass of ToolChain so it can pass *this to the GCCInstallationDetector constructor. I think that change would not be too intrusive.

[michaelplatings]

Put "experimental" in the argument name. The intention is to include the new multilib as an experimental feature in LLVM 17 and stabilise it in LLVM 18.

Also remove support for -f(no-)experimental-relative-c++-abi-vtables from the new multilib since Fuchsia no longer needs it.

[michaelplatings]

Print flags expanded by any regular expression matchers in multilib.yaml

[michaelplatings]

clang/lib/Driver/Driver.cpp

2221

Should be working now.

[michaelplatings]

Bugfix: if -msoft-float is set then -mfpu should be none.

[peter.smith]

clang/include/clang/Driver/Options.td

4333

any particular reason for using multi rather than multilib? Is there any intent to use this anywhere else?

clang/include/clang/Driver/ToolChain.h

289

Could be worth using "The command line arguments ..." when I first read I didn't pick up on the distinction between flags and arguments. IIUC this function translates command line arguments into normalised multilib selection flags.

303

typo "a pseudo"

clang/lib/Driver/ToolChain.cpp

176–271

IIUC this needs to contain the union of all command-line options used by all clients of the YAML but not any of the existing hard-coded Multilibs?

There is a possibility that this function could get large over time, with many Toolchain and Architecture specific flags? It is it worth delegating some of the work to the Toolchain, for example at the moment the BareMetal driver won't support the sanitizers so this could be processed by a Toolchain specific function (Fuchsia in this case?). There's likely to be a lot of options used by many Multilib implementations so there is still scope for putting stuff here. We would need to know what driver and architecture we are using here though.

If we had already constructed the MultilibSet it could be possible to filter the flags against what the MultilibSet actually accepts?

Is it worth making that clear, or have some way for the other non YAML users to call print_multi_selection_flags? Or is the option purely for developing/debugging multilib as I'd not expect the output of print_multi_section flags to be used by a user of clang. In that case a translation of what command-line flags influence multilib selection (ideally filtered) through the processed YAML file would be great.

223

Even though it might still live in this file, might be worth having all options for a particular arch in a separate function. For example:

case llvm::Triple::arm:
case llvm::Triple::armeb:
case llvm::Triple::thumb:
case llvm::Triple::thumbeb:
  addArmArchFlags(); // not put any thought into parameters etc.

228

Can we handle the A profile situation where effectively we have v8 + a list of features, with each v8.x and v9.y enabling a set of features https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

Ideally we would want to be able to do things like map v8.5-a+sve+sve2 and v9 to the same libraries.

247

I'm wondering if instead of using the FPU name we use a string representation of the properties for the flags. For example FK_VFPV3_D16 this would be akin to expanding march=armv8.6 to a list of target features. We'd need to make a stable string representation but I think that should be possible.

clang/test/Driver/print-multi-selection-flags.c

41

Would be useful to have some Armv7-A and Armv8-A tests as well. In particular I'm thinking of Arm-v8 and Arm-v8.1 as LSE atomics appear in v8.1.

[michaelplatings]

Rebase

[michaelplatings]

Apply improvements suggested by @peter.smith

[michaelplatings]

clang/include/clang/Driver/Options.td

4333

The reason is consistency with -print-multi-directory.

clang/lib/Driver/ToolChain.cpp

176–271

Correct, we don't yet need to cater for existing hard-coded Multilibs.

I did think about putting some argument processing in ToolChain subclasses but for now I'm inclined to say YAGNI. If it's needed later on that's an easy refactoring. With the current form, there's less likelihood of different ToolChain subclasses diverging in the style of attributes they emit.

MultilibSet can use a regex, and both matching and not matching can be significant, so I'm not sure it makes sense to filter against that.

-print-multi-selection-flags-experimental can be used completely independently of any YAML or whether the current ToolChain class actually supports multilib. -print-multi-selection-flags-experimental is intended primarily for developing/debugging multilib.

228

Yes. I added AArch64 support and it works exactly as you hoped for v8.5-a+sve+sve2 and v9.

247

ARM::getFPUFeatures does return a list of features like fp-armv8d16 and fullfp16 but AFAIK these names are unstable. I agree a stable string representation should be possible, but unless there's an existing list of stable FPU feature names I think that won't be quick. There's an opportunity cost to not landing this patch so I'd rather not delay that long. This new multilib feature won't be stable until LLVM 18 at the earliest so we can take out the mfpu=... attributes if we can agree on a better representation before then.

clang/test/Driver/print-multi-selection-flags.c

41

I didn't see anything particularly interesting to check about v7a but I added a test for -march=armv8-a+lse

[peter.smith]

Thanks for the updates, changes look good to me. I think that we can get away without trying to break the floating point options into flags, at least for how floating point units are available in hardware today.

clang/lib/Driver/ToolChain.cpp

176–271

Thinking about Arm floating point modelling (not really relevant to the mechanism here). Certainly since the Cortex cores the instructions available to an FPU are tied to the architecture. I.e. you cannot mix and match a FPU from an earlier or later architecture revision in practice, even if you can put it on the command-line in theory. I think this means that in the majority of cases we just need to match the floating point libraries with the architecture. The exceptions are the floating point variants with cut-down functionality:

• single-precision only (a nightmare of hard-float for floats and soft-float for doubles)
• d16 (only 16 double precision registers available rather than 32. I would expect this to be interface compatible with code compiled with 32-double precision registers as the calling convention doesn't change). All single-precision only are also d16.

I think these fpu options are restricted to Cortex-M and Cortex-R.

For a small number of targets we'd likely need at least two (single only, and d16) and at most 3 (single only, d16, and full) floating point variants. We'd need to map the fpu name suitable for the architecture but I don't think we would want to work too hard trying to map an arbitrary floating point unit that there is no available hardware for.

[MaskRay]

Add -print-multi-selection-flags argument

"option" is a better term. Since the option doesn't take an argument, "flag" applies as well.

[Driver] Add -print-multi-selection-flags

The summary is empty. Is that intended? We need some description what the new option does.

clang/lib/Driver/ToolChain.cpp

274

remove braces

298

This function overly uses blank lines.

// Sort and remove duplicates.
std::sort(Result.begin(), Result.end());
Result.erase(std::unique(Result.begin(), Result.end()), Result.end());
return Result;

[michaelplatings]

Remove braces and blank lines as requested by @MaskRay

[michaelplatings]

flags -> tags

[peter.smith]

I've set approved from the Arm side. Please leave some time for people in the US time zone to leave any final comments or ask for extensions.

[phosek]

clang/lib/Driver/ToolChain.cpp

238–246

Would it be possible to add this information to https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Driver/Options.td? I think that would be more maintainable.

clang/lib/Driver/ToolChains/Arch/ARM.cpp

467

Can we use ARM::FPUKind as a type here?

585

Is this variable used anywhere in this function?

clang/lib/Driver/ToolChains/Arch/ARM.h

67

Using output argument isn't very common in LLVM and even in this particular case seems a bit ad-hoc. I'm wondering if we could instead extract this logic into a new function, for example getARMFPUFeatures?

[michaelplatings]

tags->flags

[michaelplatings]

Rebase

[michaelplatings]

Rebase on D146141

[michaelplatings]

clang/lib/Driver/ToolChain.cpp

238–246

I thought about that, and it would be nice - it's a shame that this information gets copy-pasted across the Clang sources - there are already 5 or so places that do this. However for this change I think that would be too much scope creep so I've stuck with the status quo.

clang/lib/Driver/ToolChains/Arch/ARM.cpp

467

I made a new change, D146141, that makes this possible. I've rebased this patch on that change now so this is done.

585

Yes, although previously in this scope only for FPUID == llvm::ARM::FK_NONE. Now we're using it more since we're returning it.

clang/lib/Driver/ToolChains/Arch/ARM.h

67

It's not unusual in this area of the code. Usually the name is ArgFPUKind which I don't find descriptive so I went with OutFPUKind to make it clearer that it's an output of the function. However since the function had return type void I've now simply changed it to return FPUKind directly.

I spent a chunk of time looking into whether I could get a separate FPU-specific function. Finding the FPU is tightly coupled across a lot of code with finding the architecture and CPU. Although I'm sure the code could be better structured, the problem is also inherent because the floating point support is dependent on -mfpu, -march, -mcpu, --target, -mfloat-abi and possibly others so figuring everything out requires parsing many options. In short, I think returning FPUKind is the lesser evil here, even if it does seem a bit ad-hoc.

[michaelplatings]

Rebase

[michaelplatings]

Rebase

[michaelplatings]

Rebase

[phosek]

clang/lib/Driver/ToolChain.cpp

250–285

I'd suggest omitting these for the initial version. Ideally we would find a way to specify these more generally through Clang's option parser rather than individually listing all flags here, but that can be done in a follow up change.

[phosek]

clang/include/clang/Driver/Options.td

4333

This is just a suggestion, but I'd consider dropping selection, that is the name of the flag would be just -print-multi-flags. It's not clear to me what the "selection" means in this context and I'm not sure if it provides any additional value.

[michaelplatings]

Rename option and support fewer options as suggested by @phosek

[phosek]

LGTM

[michaelplatings]

Rebase

[MaskRay]

clang/lib/Driver/ToolChain.cpp

266

clang/include/clang/Driver/Options.td

 def print_ivar_layout : Flag<["-"], "print-ivar-layout">, Flags<[CC1Option]>,
   HelpText<"Enable Objective-C Ivar layout bitmap print trace">,
   MarshallingInfoFlag<LangOpts<"ObjCGCBitmapPrint">>;
 def print_libgcc_file_name : Flag<["-", "--"], "print-libgcc-file-name">,
   HelpText<"Print the library path for the currently used compiler runtime "
            "library (\"libgcc.a\" or \"libclang_rt.builtins.*.a\")">;
 def print_multi_directory : Flag<["-", "--"], "print-multi-directory">;
 def print_multi_lib : Flag<["-", "--"], "print-multi-lib">;
+def print_multi_flags : Flag<["-", "--"], "print-multi-flags-experimental">,
+  HelpText<"Print the flags used for selecting multilibs (experimental)">;
 def print_multi_os_directory : Flag<["-", "--"], "print-multi-os-directory">,
   Flags<[Unsupported]>;
 def print_target_triple : Flag<["-", "--"], "print-target-triple">,
   HelpText<"Print the normalized target triple">, Flags<[FlangOption]>;
 def print_effective_triple : Flag<["-", "--"], "print-effective-triple">,
   HelpText<"Print the effective target triple">, Flags<[FlangOption]>;
 // GCC --disable-multiarch, GCC --enable-multiarch (upstream and Debian
 // specific) have different behaviors. We choose not to support the option.

clang/include/clang/Driver/ToolChain.h

public:
 
   path_list &getProgramPaths() { return ProgramPaths; }
   const path_list &getProgramPaths() const { return ProgramPaths; }
 
   const MultilibSet &getMultilibs() const { return Multilibs; }
 
   const Multilib &getMultilib() const { return SelectedMultilib; }
 
+  /// Get flags suitable for multilib selection, based on the provided clang
+  /// command line arguments. The command line arguments aren't suitable to be
+  /// used directly for multilib selection because they are not normalized and
+  /// normalization is a complex process. The result of this function is similar
+  /// to clang command line arguments except that the list of arguments is
+  /// incomplete. Only certain command line arguments are processed. If more
+  /// command line arguments are needed for multilib selection then this
+  /// function should be extended.
+  /// To allow users to find out what flags are returned, clang accepts a
+  /// -print-multi-flags-experimental argument.
+  Multilib::flags_list getMultilibFlags(const llvm::opt::ArgList &) const;
+
   SanitizerArgs getSanitizerArgs(const llvm::opt::ArgList &JobArgs) const;
 
   const XRayArgs& getXRayArgs() const;
 
   // Returns the Arg * that explicitly turned on/off rtti, or nullptr.
   const llvm::opt::Arg *getRTTIArg() const { return CachedRTTIArg; }
 
   // Returns the RTTIMode for the toolchain with the current arguments.
   RTTIMode getRTTIMode() const { return CachedRTTIMode; }
 
   /// Return any implicit target and/or mode flag for an invocation of
   /// the compiler driver as `ProgName`.

clang/lib/Driver/Driver.cpp

bool Driver::HandleImmediateArgs(const Compilation &C) {
   }
 
   if (C.getArgs().hasArg(options::OPT_print_multi_lib)) {
     for (const Multilib &Multilib : TC.getMultilibs())
       llvm::outs() << Multilib << "\n";
     return false;
   }
 
+  if (C.getArgs().hasArg(options::OPT_print_multi_flags)) {
+    Multilib::flags_list ArgFlags = TC.getMultilibFlags(C.getArgs());
+    llvm::StringSet<> ExpandedFlags = TC.getMultilibs().expandFlags(ArgFlags);
+    std::set<llvm::StringRef> SortedFlags;
+    for (const auto &FlagEntry : ExpandedFlags)
+      SortedFlags.insert(FlagEntry.getKey());
+    for (auto Flag : SortedFlags)
+      llvm::outs() << Flag << '\n';
+    return false;
+  }
+
   if (C.getArgs().hasArg(options::OPT_print_multi_directory)) {
     const Multilib &Multilib = TC.getMultilib();
     if (Multilib.gccSuffix().empty())
       llvm::outs() << ".\n";
     else {
       StringRef Suffix(Multilib.gccSuffix());
       assert(Suffix.front() == '/');
       llvm::outs() << Suffix.substr(1) << "\n";

clang/lib/Driver/ToolChain.cpp

 //===- ToolChain.cpp - Collections of tools for one platform --------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "clang/Driver/ToolChain.h"
+#include "ToolChains/Arch/AArch64.h"
 #include "ToolChains/Arch/ARM.h"
 #include "ToolChains/Clang.h"
+#include "ToolChains/CommonArgs.h"
 #include "ToolChains/Flang.h"
 #include "ToolChains/InterfaceStubs.h"
 #include "clang/Basic/ObjCRuntime.h"
 #include "clang/Basic/Sanitizers.h"
 #include "clang/Config/config.h"
 #include "clang/Driver/Action.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"

 #include "llvm/Option/OptTable.h"
 #include "llvm/Option/Option.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VersionTuple.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include "llvm/TargetParser/AArch64TargetParser.h"
 #include "llvm/TargetParser/TargetParser.h"
 #include "llvm/TargetParser/Triple.h"
 #include <cassert>
 #include <cstddef>
 #include <cstring>
 #include <string>
 
 using namespace clang;

 
 bool ToolChain::useRelaxRelocations() const {
   return ENABLE_X86_RELAX_RELOCATIONS;
 }
 
 bool ToolChain::defaultToIEEELongDouble() const {
   return PPC_LINUX_DEFAULT_IEEELONGDOUBLE && getTriple().isOSLinux();
 }
 
+static void getAArch64MultilibFlags(const Driver &D,
+                                          const llvm::Triple &Triple,
+                                          const llvm::opt::ArgList &Args,
+                                          Multilib::flags_list &Result) {
+  std::vector<StringRef> Features;
+  tools::aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, false);
+  const auto UnifiedFeatures = tools::unifyTargetFeatures(Features);
+  llvm::DenseSet<StringRef> FeatureSet(UnifiedFeatures.begin(),
+                                       UnifiedFeatures.end());
+  std::vector<std::string> MArch;
+  for (const auto &Ext : AArch64::Extensions)
+    if (FeatureSet.find(Ext.Feature) != FeatureSet.end())
+      MArch.push_back(Ext.Name.str());
+  for (const auto &Ext : AArch64::Extensions)
+    if (FeatureSet.find(Ext.NegFeature) != FeatureSet.end())
+      MArch.push_back(("no" + Ext.Name).str());
+  MArch.insert(MArch.begin(), ("-march=" + Triple.getArchName()).str());
+  Result.push_back(llvm::join(MArch, "+"));
+}
+
+static void getARMMultilibFlags(const Driver &D,
+                                      const llvm::Triple &Triple,
+                                      const llvm::opt::ArgList &Args,
+                                      Multilib::flags_list &Result) {
+  std::vector<StringRef> Features;
+  llvm::ARM::FPUKind FPUKind =
+      tools::arm::getARMTargetFeatures(D, Triple, Args, Features, false);
+  const auto UnifiedFeatures = tools::unifyTargetFeatures(Features);
+  llvm::DenseSet<StringRef> FeatureSet(UnifiedFeatures.begin(),
+                                       UnifiedFeatures.end());
+  std::vector<std::string> MArch;
+  for (const auto &Ext : ARM::ARCHExtNames)
+    if (FeatureSet.find(Ext.Feature) != FeatureSet.end())
+      MArch.push_back(Ext.Name.str());
+  for (const auto &Ext : ARM::ARCHExtNames)
+    if (FeatureSet.find(Ext.NegFeature) != FeatureSet.end())
+      MArch.push_back(("no" + Ext.Name).str());
+  MArch.insert(MArch.begin(), ("-march=" + Triple.getArchName()).str());
+  Result.push_back(llvm::join(MArch, "+"));
+
+  switch (FPUKind) {
+#define ARM_FPU(NAME, KIND, VERSION, NEON_SUPPORT, RESTRICTION)                \
+  case llvm::ARM::KIND:                                                        \
+    Result.push_back("-mfpu=" NAME);                                           \
+    break;
+#include "llvm/TargetParser/ARMTargetParser.def"
+  default:
+    llvm_unreachable("Invalid FPUKind");
+  }
+
+  switch (arm::getARMFloatABI(D, Triple, Args)) {
+  case arm::FloatABI::Soft:
+    Result.push_back("-mfloat-abi=soft");
+    break;
+  case arm::FloatABI::SoftFP:
+    Result.push_back("-mfloat-abi=softfp");
+    break;
+  case arm::FloatABI::Hard:
+    Result.push_back("-mfloat-abi=hard");
+    break;
+  case arm::FloatABI::Invalid:
+    llvm_unreachable("Invalid float ABI");
+  }
+}
+
+Multilib::flags_list
+ToolChain::getMultilibFlags(const llvm::opt::ArgList &Args) const {
+  using namespace clang::driver::options;
+
+  std::vector<std::string> Result;
+  const llvm::Triple Triple(ComputeEffectiveClangTriple(Args));
+  Result.push_back("--target=" + Triple.str());
+
+  switch (Triple.getArch()) {
+  case llvm::Triple::aarch64:
+  case llvm::Triple::aarch64_32:
+  case llvm::Triple::aarch64_be:
+    getAArch64MultilibFlags(D, Triple, Args, Result);
+    break;
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb:
+    getARMMultilibFlags(D, Triple, Args, Result);
+    break;
+  default:
+    break;
+  }
+
+  // Sort and remove duplicates.
+  std::sort(Result.begin(), Result.end());
+  Result.erase(std::unique(Result.begin(), Result.end()), Result.end());
+  return Result;
+}
+
 SanitizerArgs
 ToolChain::getSanitizerArgs(const llvm::opt::ArgList &JobArgs) const {
   SanitizerArgs SanArgs(*this, JobArgs, !SanitizerArgsChecked);
   SanitizerArgsChecked = true;
   return SanArgs;
 }
 
 const XRayArgs& ToolChain::getXRayArgs() const {
   if (!XRayArguments)
     XRayArguments.reset(new XRayArgs(*this, Args));
   return *XRayArguments;
 }
 
 namespace {
 
 struct DriverSuffix {
   const char *Suffix;
   const char *ModeFlag;
 };
 
 } // namespace
 
 static const DriverSuffix *FindDriverSuffix(StringRef ProgName, size_t &Pos) {
   // A list of known driver suffixes. Suffixes are compared against the
   // program name in order. If there is a match, the frontend type is updated as
   // necessary by applying the ModeFlag.
   static const DriverSuffix DriverSuffixes[] = {
       {"clang", nullptr},
       {"clang++", "--driver-mode=g++"},
       {"clang-c++", "--driver-mode=g++"},
       {"clang-cc", nullptr},
       {"clang-cpp", "--driver-mode=cpp"},
       {"clang-g++", "--driver-mode=g++"},
       {"clang-gcc", nullptr},
       {"clang-cl", "--driver-mode=cl"},

clang/lib/Driver/ToolChains/Arch/ARM.h

ReadTPMode getReadTPMode(const Driver &D, const llvm::opt::ArgList &Args,
                          const llvm::Triple &Triple, bool ForAS);
 void setArchNameInTriple(const Driver &D, const llvm::opt::ArgList &Args,
                          types::ID InputType, llvm::Triple &Triple);
 
 bool useAAPCSForMachO(const llvm::Triple &T);
 void getARMArchCPUFromArgs(const llvm::opt::ArgList &Args,
                            llvm::StringRef &Arch, llvm::StringRef &CPU,
                            bool FromAs = false);
-void getARMTargetFeatures(const Driver &D, const llvm::Triple &Triple,
+llvm::ARM::FPUKind getARMTargetFeatures(const Driver &D,
+                                        const llvm::Triple &Triple,
                                         const llvm::opt::ArgList &Args,
-                          std::vector<llvm::StringRef> &Features, bool ForAS);
+                                        std::vector<llvm::StringRef> &Features,
+                                        bool ForAS);
 int getARMSubArchVersionNumber(const llvm::Triple &Triple);
 bool isARMMProfile(const llvm::Triple &Triple);
 bool isARMAProfile(const llvm::Triple &Triple);
 
 } // end namespace arm
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
 
 #endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_ARCH_ARM_H

clang/lib/Driver/ToolChains/Arch/ARM.cpp

 
 static bool hasIntegerMVE(const std::vector<StringRef> &F) {
   auto MVE = llvm::find(llvm::reverse(F), "+mve");
   auto NoMVE = llvm::find(llvm::reverse(F), "-mve");
   return MVE != F.rend() &&
          (NoMVE == F.rend() || std::distance(MVE, NoMVE) > 0);
 }
 
-void arm::getARMTargetFeatures(const Driver &D, const llvm::Triple &Triple,
+llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver &D,
+                                             const llvm::Triple &Triple,
                                              const ArgList &Args,
-                               std::vector<StringRef> &Features, bool ForAS) {
+                                             std::vector<StringRef> &Features,
+                                             bool ForAS) {
   bool KernelOrKext =
       Args.hasArg(options::OPT_mkernel, options::OPT_fapple_kext);
   arm::FloatABI ABI = arm::getARMFloatABI(D, Triple, Args);
   std::optional<std::pair<const Arg *, StringRef>> WaCPU, WaFPU, WaHDiv, WaArch;
 
   // This vector will accumulate features from the architecture
   // extension suffixes on -mcpu and -march (e.g. the 'bar' in
   // -mcpu=foo+bar). We want to apply those after the features derived
if (CPUArg)
     checkARMCPUName(D, CPUArg, Args, CPUName, ArchName, ExtensionFeatures,
                     Triple, CPUArgFPUKind);
 
   // TODO Handle -mtune=. Suppress -Wunused-command-line-argument as a
   // longstanding behavior.
   (void)Args.getLastArg(options::OPT_mtune_EQ);
 
   // Honor -mfpu=. ClangAs gives preference to -Wa,-mfpu=.
   llvm::ARM::FPUKind FPUKind = llvm::ARM::FK_INVALID;
   const Arg *FPUArg = Args.getLastArg(options::OPT_mfpu_EQ);
   if (WaFPU) {
     if (FPUArg)
       D.Diag(clang::diag::warn_drv_unused_argument)
           << FPUArg->getAsString(Args);
     (void)getARMFPUFeatures(D, WaFPU->first, Args, WaFPU->second, Features);
   } else if (FPUArg) {
     FPUKind = getARMFPUFeatures(D, FPUArg, Args, FPUArg->getValue(), Features);
fp16_fml_fallthrough:
   if (ABI == arm::FloatABI::Soft) {
     llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
     // Disable all features relating to hardware FP, not already disabled by the
     // above call.
     Features.insert(Features.end(),
                     {"-dotprod", "-fp16fml", "-bf16", "-mve", "-mve.fp"});
     HasFPRegs = false;
+    FPUKind = llvm::ARM::FK_NONE;
   } else if (FPUKind == llvm::ARM::FK_NONE ||
              ArchArgFPUKind == llvm::ARM::FK_NONE ||
              CPUArgFPUKind == llvm::ARM::FK_NONE) {
     // -mfpu=none, -march=armvX+nofp or -mcpu=X+nofp is *very* similar to
     // -mfloat-abi=soft, only that it should not disable MVE-I. They disable the
     // FPU, but not the FPU registers, thus MVE-I, which depends only on the
     // latter, is still supported.
     Features.insert(Features.end(),
                     {"-dotprod", "-fp16fml", "-bf16", "-mve.fp"});
     HasFPRegs = hasIntegerMVE(Features);
+    FPUKind = llvm::ARM::FK_NONE;
   }
   if (!HasFPRegs)
     Features.emplace_back("-fpregs");
 
   // En/disable crc code generation.
   if (Arg *A = Args.getLastArg(options::OPT_mcrc, options::OPT_mnocrc)) {
     if (A->getOption().matches(options::OPT_mcrc))
       Features.push_back("+crc");
if (DisableComdat) {
       Features.push_back("+harden-sls-nocomdat");
     }
   }
 
   if (Args.getLastArg(options::OPT_mno_bti_at_return_twice))
     Features.push_back("+no-bti-at-return-twice");
 
   checkARMFloatABI(D, Args, HasFPRegs);
+
+  return FPUKind;
 }
 
 std::string arm::getARMArch(StringRef Arch, const llvm::Triple &Triple) {
   std::string MArch;
   if (!Arch.empty())
     MArch = std::string(Arch);
   else
     MArch = std::string(Triple.getArchName());

clang/test/Driver/print-multi-selection-flags.c

+// RUN: %clang -print-multi-flags-experimental --target=aarch64-linux -fc++-abi=itanium -fsanitize=address | FileCheck --check-prefix=CHECK-LINUX %s
+// CHECK-LINUX: --target=aarch64-unknown-linux
+
+// RUN: %clang -print-multi-flags-experimental --target=aarch64-fuchsia -fsanitize=hwaddress | FileCheck --check-prefix=CHECK-FUCHSIA %s
+// CHECK-FUCHSIA: --target=aarch64-unknown-fuchsia
+
+// RUN: %clang -print-multi-flags-experimental --target=arm-none-eabi -mfloat-abi=soft -fno-exceptions -fno-rtti | FileCheck --check-prefix=CHECK-ARMV4T %s
+// CHECK-ARMV4T: --target=armv4t-none-unknown-eabi
+// CHECK-ARMV4T: -mfloat-abi=soft
+// CHECK-ARMV4T: -mfpu=none
+
+// RUN: %clang -print-multi-flags-experimental --target=armv7em-none-eabi -mfloat-abi=softfp | FileCheck --check-prefix=CHECK-SOFTFP %s
+// CHECK-SOFTFP: --target=thumbv7em-none-unknown-eabi
+// CHECK-SOFTFP: -mfloat-abi=softfp
+// CHECK-SOFTFP: -mfpu=fpv4-sp-d16
+
+// RUN: %clang -print-multi-flags-experimental --target=arm-none-eabihf -march=armv7em -mfpu=fpv5-d16 | FileCheck --check-prefix=CHECK-HARD %s
+// CHECK-HARD: --target=thumbv7em-none-unknown-eabihf
+// CHECK-HARD: -mfloat-abi=hard
+// CHECK-HARD: -mfpu=fpv5-d16
+
+// RUN: %clang -print-multi-flags-experimental --target=arm-none-eabi -mfloat-abi=soft -march=armv8-m.main+nofp | FileCheck --check-prefix=CHECK-V8MMAIN-NOFP %s
+// CHECK-V8MMAIN-NOFP: --target=thumbv8m.main-none-unknown-eabi
+// CHECK-V8MMAIN-NOFP: -mfloat-abi=soft
+// CHECK-V8MMAIN-NOFP: -mfpu=none
+
+// RUN: %clang -print-multi-flags-experimental --target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+mve.fp | FileCheck --check-prefix=CHECK-MVE %s
+// CHECK-MVE: --target=thumbv8.1m.main-none-unknown-eabihf
+// CHECK-MVE: -march=thumbv8.1m.main{{.*}}+mve{{.*}}+mve.fp{{.*}}
+// CHECK-MVE: -mfloat-abi=hard
+// CHECK-MVE: -mfpu=fp-armv8-fullfp16-sp-d16
+
+// RUN: %clang -print-multi-flags-experimental --target=arm-none-eabi -march=armv8.1m.main+mve+nofp | FileCheck --check-prefix=CHECK-MVENOFP %s
+// CHECK-MVENOFP: -march=thumbv8.1m.main{{.*}}+mve{{.*}}
+// CHECK-MVENOFP-NOT: -march=thumbv8.1m.main{{.*}}+mve.fp{{.*}}
+// CHECK-MVENOFP: -mfpu=none
+
+// RUN: %clang -print-multi-flags-experimental --target=aarch64-none-elf -march=armv8-a+lse | FileCheck --check-prefix=CHECK-LSE %s
+// CHECK-LSE: -march=aarch64{{.*}}+lse{{.*}}
+
+// RUN: %clang -print-multi-flags-experimental --target=aarch64-none-elf -march=armv8.5-a+sve+sve2 | FileCheck --check-prefix=CHECK-SVE2 %s
+// RUN: %clang -print-multi-flags-experimental --target=aarch64-none-elf -march=armv9-a            | FileCheck --check-prefix=CHECK-SVE2 %s
+// CHECK-SVE2: --target=aarch64-none-unknown-elf
+// CHECK-SVE2: -march=aarch64{{.*}}+simd{{.*}}+sve{{.*}}+sve2{{.*}}