This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Generate march string from target features
ClosedPublic

Authored by pcwang-thead on Jan 11 2023, 4:16 AM.

Details

Summary

As what has been mentioned in D137517, this patch is to simplify
processors definitions in RISCV.td. We don't have to specify march
string since we can generate it from target features.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 4:16 AM
pcwang-thead requested review of this revision.Jan 11 2023, 4:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 4:16 AM
fpetrogalli added inline comments.Jan 11 2023, 7:00 AM
llvm/utils/TableGen/RISCVTargetDefEmitter.cpp
59

I think you should reference here the pieces of the standard that describe the rules for building the March string.

60

Do you need this variable? it is used only once...

67

I think you can avoid constructing a std::string here?

70

Please avoid auto if the type cannot be deducted from the context.

75

Do we need this variable? It is used only once...

76

You could use StringRef and then check MArch.empty() in line 70.

Address comments.

pcwang-thead marked 3 inline comments as done.

Reduce constructions of std::string.

pcwang-thead marked 3 inline comments as done.Jan 11 2023, 7:28 PM

Fix errors caused by destroyed string.

llvm/utils/TableGen/RISCVTargetDefEmitter.cpp
76

getMArch() returns std::string, if I change type of MArch from std::string to StringRef, it would be:

if (MArch.empty())
        MArch = StringRef(getMArch(XLen, Rec));

The string will be destroyed and cause errors like https://buildkite.com/llvm-project/premerge-checks/builds/130218.
So I think it is no bother to do that.

fpetrogalli accepted this revision.Jan 12 2023, 1:34 AM

LGTM, with some minor observations:

  1. You say The disadvantage is that the generated march string is too tedious.. That does seems to imply that autogenerating the string is not a good idea? I'd remove it from the commit message.
  1. I am still thinking you should reference the bits of the RISCV specs that describe how to create MArch out of the features.

Thank you!

Francesco

llvm/utils/TableGen/RISCVTargetDefEmitter.cpp
68

Nit - maybe if you set std::vector<StringRef> FeatureVector; you can avoid the .str() in here?

71

Nit: maybe alias the type in the body of the function?

using ISAInfoTy = llvm::Expected<std::unique_ptr<RISCVISAInfo>>;
ISAInfoTy ISAInfo = ...
This revision is now accepted and ready to land.Jan 12 2023, 1:34 AM
  • Add reference to RISCV spec.
  • Address comments.
pcwang-thead edited the summary of this revision. (Show Details)Jan 13 2023, 2:02 AM
pcwang-thead marked 2 inline comments as done.
pcwang-thead added inline comments.
llvm/utils/TableGen/RISCVTargetDefEmitter.cpp
68

I'm afraid not, because we expect std::vector<std::string> in llvm::RISCVISAInfo::parseFeatures.

fpetrogalli accepted this revision.Jan 13 2023, 2:50 AM
fpetrogalli added inline comments.
llvm/utils/TableGen/RISCVTargetDefEmitter.cpp
33

Nit: link to the specific version, or mention the version.

68

Oh - OK - thanks

kito-cheng accepted this revision.Jan 13 2023, 3:09 AM

LGTM, Ilike this improvement, it's further simplified the step of adding a new CPU info.

pcwang-thead marked an inline comment as done.
  • Rebase.
  • Add spec version.
pcwang-thead marked an inline comment as done.Jan 15 2023, 7:07 PM
This revision was landed with ongoing or failed builds.Jan 15 2023, 8:04 PM
This revision was automatically updated to reflect the committed changes.