[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

2213

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

204

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

2213

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

clang/lib/Driver/ToolChain.cpp

204

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

2213

Should be working now.

[michaelplatings]

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

[peter.smith]

clang/include/clang/Driver/Options.td

4158

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

174–280

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.

221

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.

226

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.

245

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

4158

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

clang/lib/Driver/ToolChain.cpp

174–280

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.

226

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

245

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

174–280

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

272

remove braces

296

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

236–244

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

442

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

557

Is this variable used anywhere in this function?

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

71

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

236–244

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

442

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

557

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

71

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

248–283

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

4158

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

264

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_selection_flags : Flag<["-", "--"], "print-multi-selection-flags">,
+  HelpText<"Print the flags used for selecting multilibs">;
 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 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 but different:
+  /// * It's incomplete. Only certain arguments are processed. If more arguments
+  ///   are needed for multilib selection then this function should be extended.
+  /// * The flags aren't prefixed with "-".
+  /// * Where a single command line argument would contain a list, the elements
+  ///   are split out. For example, Arm extensions are appended to -march like
+  ///   -march=armv8m.main+crc+crypto+sha2+mve. Since this function is
+  ///   incomplete, a later clang version may infer the presence of more
+  ///   extensions than an earlier version. If all extensions were in a single
+  ///   flag then that would be unstable. Instead, each extension will be
+  ///   returned separately. There may not be valid syntax to express this as a
+  ///   clang argument so an pseudo argument syntax must be used instead.
+  /// To allow users to find out what flags are returned, clang accepts a
+  /// -print-multi-selection-flags argument.
+  std::vector<std::string>
+  getMultiSelectionFlags(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.

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_selection_flags)) {
+    for (StringRef Attr : TC.getMultiSelectionFlags(C.getArgs()))
+      llvm::outs() << Attr << '\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/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/Basic/TargetCXXABI.h"
 #include "clang/Config/config.h"
 #include "clang/Driver/Action.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/InputInfo.h"
 #include "clang/Driver/Job.h"
 #include "clang/Driver/Options.h"
 #include "clang/Driver/SanitizerArgs.h"

 
 bool ToolChain::useRelaxRelocations() const {
   return ENABLE_X86_RELAX_RELOCATIONS;
 }
 
 bool ToolChain::defaultToIEEELongDouble() const {
   return PPC_LINUX_DEFAULT_IEEELONGDOUBLE && getTriple().isOSLinux();
 }
 
+std::vector<std::string>
+ToolChain::getMultiSelectionFlags(const llvm::opt::ArgList &Args) const {
+  std::vector<std::string> Result;
+
+  using namespace clang::driver::options;
+
+  const llvm::Triple Triple(ComputeEffectiveClangTriple(Args));
+
+  // Enumerate boolean flags we care about for the purposes of multilib here.
+  // There must be a smarter way to do it but this gets us started.
+  const struct HasFlag {
+    ID Pos, Neg;
+    bool Default;
+  } HasFlagList[] = {
+      {OPT_fexceptions, OPT_fno_exceptions, true},
+      {OPT_frtti, OPT_fno_rtti, true},
+      {OPT_fexperimental_relative_cxx_abi_vtables,
+       OPT_fno_experimental_relative_cxx_abi_vtables,
+       TargetCXXABI::usesRelativeVTables(Triple)},
+  };
+
+  // Options we care about that have a single last-wins value.
+  static const ID GetLastArgValue[] = {
+      OPT_fcxx_abi_EQ,
+  };
+
+  for (const HasFlag &HF : HasFlagList) {
+    ID Option = Args.hasFlag(HF.Pos, HF.Neg, HF.Default) ? HF.Pos : HF.Neg;
+    Result.push_back(
+        clang::driver::getDriverOptTable().getOptionName(Option).str());
+  }
+
+  for (ID Option : GetLastArgValue) {
+    StringRef Value = Args.getLastArgValue(Option);
+    if (!Value.empty()) {
+      Result.push_back(
+          (clang::driver::getDriverOptTable().getOptionName(Option) + Value)
+              .str());
+    }
+  }
+
+  const SanitizerArgs SanArgs(getSanitizerArgs(Args));
+  if (SanArgs.needsAsanRt()) {
+    Result.push_back("fsanitize=address");
+  }
+  if (SanArgs.needsHwasanRt()) {
+    Result.push_back("fsanitize=hwaddress");
+  }
+
+  switch (Triple.getArch()) {
+  case llvm::Triple::arm:
+  case llvm::Triple::armeb:
+  case llvm::Triple::thumb:
+  case llvm::Triple::thumbeb: {
+    std::vector<StringRef> Features;
+    unsigned FPUKind = llvm::ARM::FK_INVALID;
+    tools::arm::getARMTargetFeatures(D, Triple, Args, Features, false,
+                                     &FPUKind);
+    const auto UnifiedFeatures = tools::unifyTargetFeatures(Features);
+    llvm::DenseSet<StringRef> FeatureSet(UnifiedFeatures.begin(),
+                                         UnifiedFeatures.end());
+    for (const auto &Ext : ARM::ARCHExtNames) {
+      if (FeatureSet.find(Ext.Feature) != FeatureSet.end()) {
+        Result.push_back(("march=+" + Ext.Name).str());
+      }
+    }
+
+    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");
+    }
+  } break;
+  default:
+    break;
+  }
+
+  Result.push_back("target=" + Triple.str());
+
+  // Sort alphabetically
+  std::sort(Result.begin(), Result.end());
+
+  // Remove duplicate entries
+  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

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);
+// Optionally returns the FPUKind
 void 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,
+                          unsigned *OutFPUKind = nullptr);
 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,
                                const ArgList &Args,
-                               std::vector<StringRef> &Features, bool ForAS) {
+                               std::vector<StringRef> &Features, bool ForAS,
+                               unsigned *OutFPUKind) {
   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, CPUArgFPUID);
 
   // 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=.
   unsigned FPUID = 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) {
     FPUID = getARMFPUFeatures(D, FPUArg, Args, FPUArg->getValue(), Features);
if (ABI == arm::FloatABI::Soft) {
     // -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"});
     if (!hasIntegerMVE(Features))
       Features.emplace_back("-fpregs");
+    FPUID = llvm::ARM::FK_NONE;
   }
 
   // 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");
     else
       Features.push_back("-crc");
if (EnableBlr)
       Features.push_back("+harden-sls-blr");
     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");
+
+  if (OutFPUKind) {
+    *OutFPUKind = FPUID;
+  }
 }
 
 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-selection-flags --target=aarch64-linux -fc++-abi=itanium -fsanitize=address | FileCheck --check-prefix=CHECK-LINUX %s
+// CHECK-LINUX: fc++-abi=itanium
+// CHECK-LINUX-NEXT: fexceptions
+// CHECK-LINUX-NEXT: fno-experimental-relative-c++-abi-vtables
+// CHECK-LINUX-NEXT: frtti
+// CHECK-LINUX-NEXT: fsanitize=address
+// CHECK-LINUX-NEXT: target=aarch64-unknown-linux
+
+// RUN: %clang -print-multi-selection-flags --target=aarch64-fuchsia -fsanitize=hwaddress | FileCheck --check-prefix=CHECK-FUCHSIA %s
+// CHECK-FUCHSIA: fexperimental-relative-c++-abi-vtables
+// CHECK-FUCHSIA: fsanitize=hwaddress
+// CHECK-FUCHSIA: target=aarch64-unknown-fuchsia
+
+// RUN: %clang -print-multi-selection-flags --target=arm-none-eabi -mfloat-abi=soft -fno-exceptions -fno-rtti | FileCheck --check-prefix=CHECK-ARMV4T %s
+// CHECK-ARMV4T: fno-exceptions
+// CHECK-ARMV4T: fno-rtti
+// CHECK-ARMV4T: mfloat-abi=soft
+// CHECK-ARMV4T: mfpu=none
+// CHECK-ARMV4T: target=armv4t-none-unknown-eabi
+
+// RUN: %clang -print-multi-selection-flags --target=armv7em-none-eabi -mfloat-abi=softfp | FileCheck --check-prefix=CHECK-SOFTFP %s
+// CHECK-SOFTFP: mfloat-abi=softfp
+// CHECK-SOFTFP: mfpu=fpv4-sp-d16
+// CHECK-SOFTFP: target=thumbv7em-none-unknown-eabi
+
+// RUN: %clang -print-multi-selection-flags --target=arm-none-eabihf -march=armv7em -mfpu=fpv5-d16 | FileCheck --check-prefix=CHECK-HARD %s
+// CHECK-HARD: mfloat-abi=hard
+// CHECK-HARD: mfpu=fpv5-d16
+// CHECK-HARD: target=thumbv7em-none-unknown-eabihf
+
+// RUN: %clang -print-multi-selection-flags --target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+mve.fp | FileCheck --check-prefix=CHECK-MVE %s
+// CHECK-MVE: march=+mve
+// CHECK-MVE: march=+mve.fp
+// CHECK-MVE: mfloat-abi=hard
+// CHECK-MVE: mfpu=fp-armv8-fullfp16-sp-d16
+// CHECK-MVE: target=thumbv8.1m.main-none-unknown-eabihf
+
+// RUN: %clang -print-multi-selection-flags --target=arm-none-eabi -march=armv8.1m.main+mve+nofp | FileCheck --check-prefix=CHECK-MVENOFP %s
+// CHECK-MVENOFP: march=+mve
+// CHECK-MVENOFP-NOT: march=+mve.fp
+// CHECK-MVENOFP: mfpu=none