Add accessors for MCSubtargetInfo CPU and Feature tables

[jrmuizel]

Summary

This is needed for -C target-cpu=help and -C target-feature=help in rustc

[jrmuizel]

This comes from https://github.com/rust-lang/llvm-project/commit/015eb777cf3b1890083df90d281f504d34398815

[nikic]

LGTM. I'm not particularly familiar with this code, but don't see an issue with exposing this information. Currently MCSubtargetInfo directly incorporates the logic for printing a help text to the error stream, which is very dubious design. It should be possible to obtain the same information for printing a help text manually.

[jrmuizel]

@nikic can you land this?

[fhahn]

llvm/include/llvm/MC/MCSubtargetInfo.h

229

Can you add doc-comments for the new functions?

[jrmuizel]

Add comments

[craig.topper]

I’m not against this, but do want to mention the help text is incorrect for x86-64. It lists CPUs that don’t support 64-bit. Using one of those CPUs will trigger a fatal error. A better list is fillValidCPUList from X86TargetParser.cpp in lib/Support. It takes a mode argument. That’s the interface clang uses.

[jrmuizel]

I filed https://github.com/rust-lang/rust/issues/81148 about improving the list the Rust uses.

[jrmuizel]

Update the doc comments to be less wrong.

[nikic]

In D93789#2503709, @craig.topper wrote:

I’m not against this, but do want to mention the help text is incorrect for x86-64. It lists CPUs that don’t support 64-bit. Using one of those CPUs will trigger a fatal error. A better list is fillValidCPUList from X86TargetParser.cpp in lib/Support. It takes a mode argument. That’s the interface clang uses.

The fillValidCPUArchList() interface looks pretty annoying in that it's non-virtual. One needs to call different helper functions for each target.

[fhahn]

In D93789#2505267, @nikic wrote:

In D93789#2503709, @craig.topper wrote:

I’m not against this, but do want to mention the help text is incorrect for x86-64. It lists CPUs that don’t support 64-bit. Using one of those CPUs will trigger a fatal error. A better list is fillValidCPUList from X86TargetParser.cpp in lib/Support. It takes a mode argument. That’s the interface clang uses.

The fillValidCPUArchList() interface looks pretty annoying in that it's non-virtual. One needs to call different helper functions for each target.

The current situation with TargetParser is indeed a bit unfortunate/half baked/unfinished. But I think it wold be preferable to improve the ergonomics of fillValidCPUArchList, rather than introducing a separate interface that duplicates the functionality and sometimes provides incorrect results. IMO there should be one interface used by frontends to obtain the information about supported CPUs.

llvm/include/llvm/MC/MCSubtargetInfo.h

public:
   }
 
   /// Check whether the CPU string is valid.
   bool isCPUStringValid(StringRef CPU) const {
     auto Found = std::lower_bound(ProcDesc.begin(), ProcDesc.end(), CPU);
     return Found != ProcDesc.end() && StringRef(Found->Key) == CPU;
   }
 
+  /// Get the available CPUs.
+  ArrayRef<SubtargetSubTypeKV> getCPUTable() const { return ProcDesc; }
+
+  /// Get the available features.
+  ArrayRef<SubtargetFeatureKV> getFeatureTable() const { return ProcFeatures; }
+
   virtual unsigned getHwMode() const { return 0; }
 
   /// Return the cache size in bytes for the given level of cache.
   /// Level is zero-based, so a value of zero means the first level of
   /// cache.
   ///
   virtual Optional<unsigned> getCacheSize(unsigned Level) const;