MCSubtargetInfo: Add debugging 'features' that dump current CPU bit state

[george.burgess.iv]

Summary

It's quite useful to know which feature bits are on/off when trying to
figure out how to translate strings of clang
-march/-mfpu/-mcpu/... arguments to other compilers (e.g.,
rustc). This support doesn't seem to exist, but there's precedent for
having 'special' target strings that translate to printing to stderr.
This builds on that precedent.

I don't know how much testing *should* go into this, since it's
focused on LLVM development more than anything. It's notable that
this also breaks from existing precedent in this file -- namely, it doesn't
have a static bool that only lets us print things once. This enables
users to do things like:

"target-features" = "+foo,+dump-enabled,-bar,+dump-enabled"

So they can easily tell what effect -bar has on features enabled in
the backend.

[arsenm]

Why not add a separate flag instead of polluting the feature string?

llvm/lib/MC/MCSubtargetInfo.cpp

213

I didn’t realize we had these

[george.burgess.iv]

Why not add a separate flag instead of polluting the feature string?

I'm amenable to this if you'd prefer it. A flag would make:

"target-features" = "+foo,+dump-enabled,-bar,+dump-enabled"

require multiple llc invocations. It'd also mean we dump all of the MCSubtargetInfos that we construct in a compilation, rather than a particular one of interest in a Module. I don't think either of these are huge problems, given that this feature is purely for people debugging LLVM itself. If you'd still prefer the flag approach, please let me know and I'll do that.

llvm/lib/MC/MCSubtargetInfo.cpp

213

Yeah, I kind of stumbled upon them while trying to figure this all out :P

[craig.topper]

Not a direct comment on what's in this patch

I'm curious, as X86 is probably one of the more complicated targets, does rust make use of llvm::X86::updateImpliedFeatures and llvm::X86::getFeaturesForCPU from llvm/lib/Support/X86TargetParser.cpp? That's a large chunk of the code clang uses for feature interactions.

[george.burgess.iv]

I'm curious, as X86 is probably one of the more complicated targets, does rust make use of llvm::X86::updateImpliedFeatures and llvm::X86::getFeaturesForCPU from llvm/lib/Support/X86TargetParser.cpp? That's a large chunk of the code clang uses for feature interactions.

ripgrep says Rust never tries to directly invoke either of these. Should it? I'm not personally an expert in backend features, but it seems slightly odd to me that frontends should need to query this info when LLVM already infers much about backend features on its own.

FWIW, I noticed that the inference of SGX is missing from a few rustc invocations for certain X86 target CPUs (well, missing compared to clang, at least). Seems like that could be because Rust doesn't call the functions you mentioned. Do you think that should be a bug against rustc, or against LLVM for not realizing that SGX is a feature of some CPUs except through these llvm::X86::{updateImpliedFeatures,getFeaturesForCPU} interfaces?

[craig.topper]

In D106503#2906075, @george.burgess.iv wrote:

I'm curious, as X86 is probably one of the more complicated targets, does rust make use of llvm::X86::updateImpliedFeatures and llvm::X86::getFeaturesForCPU from llvm/lib/Support/X86TargetParser.cpp? That's a large chunk of the code clang uses for feature interactions.

ripgrep says Rust never tries to directly invoke either of these. Should it? I'm not personally an expert in backend features, but it seems slightly odd to me that frontends should need to query this info when LLVM already infers much about backend features on its own.

FWIW, I noticed that the inference of SGX is missing from a few rustc invocations for certain X86 target CPUs (well, missing compared to clang, at least). Seems like that could be because Rust doesn't call the functions you mentioned. Do you think that should be a bug against rustc, or against LLVM for not realizing that SGX is a feature of some CPUs except through these llvm::X86::{updateImpliedFeatures,getFeaturesForCPU} interfaces?

SGX is a weird because there are no backend intrinsics for it. The frontend provides some inline assembly wrappers, but that's it. There are odd gaps in which CPUs support it. We intentionally didn't infer it for CPUs in the backend because it made the code in X86.td even harder to maintain than it already is do to the non-linear inheritance.

Clang needs its own copy of the inheritance logic because clang can't depend on a target library in LLVM since the library might not be listed in LLVM_TARGETS_TO_BUILD. The features for the C builtins used by the intrinsic header files needs to be checked by the frontend. The backend will crash on unsupported intrinsics. There are also preprocessor defines the clang creates based on which features are enabled. Not sure if those clang requirements apply to rustc.

[arsenm]

llvm/lib/MC/MCSubtargetInfo.cpp

215

Probably should be help rather than dump for consistency with the others

llvm/lib/MC/MCSubtargetInfo.cpp

static void cpuHelp(ArrayRef<SubtargetSubTypeKV> CPUTable) {
 
   errs() << "Use -mcpu or -mtune to specify the target's processor.\n"
             "For example, clang --target=aarch64-unknown-linux-gui "
             "-mcpu=cortex-a35\n";
 
   PrintOnce = true;
 }
 
+/// Display help for feature and mcpu choices.
+static void PrintFullFeatureList(const FeatureBitset &FeatBits,
+                                 ArrayRef<SubtargetFeatureKV> FeatTable,
+                                 bool EnabledOnly) {
+  errs() << "Current full feature list:\n";
+  for (const SubtargetFeatureKV &Feat : FeatTable) {
+    bool IsSet = FeatBits.test(Feat.Value);
+    if (EnabledOnly && !IsSet)
+      continue;
+    errs() << "\t" << (IsSet ? '+' : '-') << Feat.Key << ":\t" << Feat.Desc
+           << '\n';
+  }
+}
+
 static FeatureBitset getFeatures(StringRef CPU, StringRef TuneCPU, StringRef FS,
                                  ArrayRef<SubtargetSubTypeKV> ProcDesc,
                                  ArrayRef<SubtargetFeatureKV> ProcFeatures) {
   SubtargetFeatures Features(FS);
 
   if (ProcDesc.empty() || ProcFeatures.empty())
     return FeatureBitset();
 
if (!TuneCPU.empty()) {
     }
   }
 
   // Iterate through each feature
   for (const std::string &Feature : Features.getFeatures()) {
     // Check for help
     if (Feature == "+help")
       Help(ProcDesc, ProcFeatures);
     else if (Feature == "+cpuhelp")
       cpuHelp(ProcDesc);
+    else if (Feature == "+dump-all")
+      PrintFullFeatureList(Bits, ProcFeatures, /*EnabledOnly=*/false);
+    else if (Feature == "+dump-enabled")
+      PrintFullFeatureList(Bits, ProcFeatures, /*EnabledOnly=*/true);
     else
       ApplyFeatureFlag(Bits, Feature, ProcFeatures);
   }
 
   return Bits;
 }
 
 void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef TuneCPU,