[RISCV] support clang driver to select cpu

[khchen]

Summary

update implementation and handle -mcpu with explicitly specified -march.
If -mcpu has default march, explicitly -march will overwrite it.

1. reference ARM/AArch64 and X86 to implement RISCVTargetParser.def
2. in clang, -mtune option alias to -mcpu. This patch supports -mtune option via -mcpu.
3. propose two category of CPUs in TargetParser and backend. First is similar gcc's -mtune option (it includes micro architecture related feature only, ex. rocket-rv32 has different schedule model), another also has default -march (isa string).
4. add two sifive cpu which has default -march
5. changed default march logic.

march: in order:

1. Explicit choices using -march
2. A default based on -mcpu, if target cpu has default -march
3. default based on -mabi, if provided
4. A default based on the target triple's arch

I think it's also okay if we want to only support -mcpu which is similar to gcc's -mtune at the moment . Because in current implementation,
users can query available CPUs via -mcpu=? on clang but mcpu option is not workable.

[Jim]

clang/lib/Basic/Targets/RISCV.h

46

I think this should test cpu name is valid first. And assign Name to CPU, if it is valid.

[lenary]

clang/lib/Basic/Targets/RISCV.cpp

165

Is there not a tablegen'd implementation of these based on https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/RISCV/RISCV.td#L96-L99 (which will include rocket-rv32 and rocket-rv64 when those two schedules are landed)?

[khchen]

clang/lib/Basic/Targets/RISCV.cpp

165

you are right, if generic-cpu uses rocket chip scheduler, it's okay to abandon this patch.

clang/lib/Basic/Targets/RISCV.h

46

yes, you are right, thanks.

[lenary]

clang/lib/Basic/Targets/RISCV.cpp

165

No, that's not quite what I mean. When we add the rocket schedules, there will be additional ProcessorModel entries for the rocket chips, in addition to the current generic models.

The point in these ProcessorModel entries is if a user passes -mcpu=generic-rv64, then [Feature64Bit, FeatureRVCHints] will get turned on, because they chose a specific cpu. This is different to validating that the correct features are enabled in order to choose a cpu, which seems the correct way around.

Then instead of checking against hard-coded lists, you use use MCSubtargetInfo::isCPUStringValid(StringRef), which uses the info from the ProcessorModel tablegen entries.

[khchen]

The problem is how -mcpu interact with explicitly specified -march (or target features).

1. in GCC, -mcpu is only used to chose the pipeline model,

2. I also read this article talking about the X86 and ARM to handle those options.

-march=X: Tells the compiler that X is the minimal architecture the binary must run on. The compiler is free to use architecture-specific instructions. This flag behaves differently on Arm and x86. On Arm, -march does not override -mtune, but on x86 -march will override both -mtune and -mcpu.
-mtune=X: Tells the compiler to optimize for microarchitecture X but does not allow the compiler to change the ABI or make assumptions about available instructions. This flag has the more-or-less the same meaning on Arm and x86.
-mcpu=X: On Arm, this flag is a combination of -march and -mtune. It simultaneously specifies the target architecture and optimizes for a given microarchitecture. On x86 this flag is a deprecated synonym for -mtune.

So maybe it makes sense to treat those flags behaves differently on different target .

3. I also tried llc to specific -mcpu and -attr (similar to -march, target-feature) in ARM, -attr will over write the default target-feature in -mcpu.

on RISC-V, in sometime (or most?) we have same pipeline model but support different extension combination,
so I think maybe distinguishing the purpose of -mcpu and -march and make them with no interaction is a good idea. (behavior is equal to GCC)

[khchen]

clang/lib/Basic/Targets/RISCV.cpp

165

@lenary
I see no backend uses the info (ex. RISCVSubTypeKV?) from tablegen entries,
I saw different targets use different way to impl. TargetInfo::isValidCPUName.
for example:
x86 uses clang/Basic/X86Target.def to record (hard-codeed) valid cpu enum and string,
arm/aarch64 uses llvm/Support/ARMTargetParser.def,
and mips just hard code the valid cpu string in clang/lib/Basic/Targets/Mips.cpp.
They don't use backend to check valid cpu string, so maybe this patch is workable.
But I wonder if you are asking this patch should implement the checking for invalid combination like -mcpu=generic-rv32 with -mattr=+64bit ?

[evandro]

clang/lib/Basic/Targets/RISCV.cpp

165

Strange formatting...

[lenary]

In D71124#1792216, @khchen wrote:

The problem is how -mcpu interact with explicitly specified -march (or target features).

1. in GCC, -mcpu is only used to chose the pipeline model,

I think you mean "in GCC, -mtune is only used to choose the pipeline model" (-mcpu is not documented in the RISC-V specific GCC options documentation).

Clang should attempt to maintain compatibility with GCC flags, but if they only implement -mtune, then we have a little more freedom to do something ergonomic with -mcpu.

I'll note that clang already has a large TODO around implementing -mtune in general, though the AArch64 backend seems to support it for some option choices.

2. I also read this article talking about the X86 and ARM to handle those options.
   • -march=X: Tells the compiler that X is the minimal architecture the binary must run on. The compiler is free to use architecture-specific instructions. This flag behaves differently on Arm and x86. On Arm, -march does not override -mtune, but on x86 -march will override both -mtune and -mcpu.
   • -mtune=X: Tells the compiler to optimize for microarchitecture X but does not allow the compiler to change the ABI or make assumptions about available instructions. This flag has the more-or-less the same meaning on Arm and x86.
   • -mcpu=X: On Arm, this flag is a combination of -march and -mtune. It simultaneously specifies the target architecture and optimizes for a given microarchitecture. On x86 this flag is a deprecated synonym for -mtune.

So maybe it makes sense to treat those flags behaves differently on different target .

3. I also tried llc to specific -mcpu and -attr (similar to -march, target-feature) in ARM, -attr will over write the default target-feature in -mcpu.

on RISC-V, in sometime (or most?) we have same pipeline model but support different extension combination,

I don't believe this to be correct. lowRISC's Ibex has a completely different pipeline model to rocket, and there are countless other RISC-V cores with different pipeline characteristics, including out-of-order pipeline implementations like BOOM. I don't think we can favour one particular scheduling model (beyond the generic ones we already default to).

so I think maybe distinguishing the purpose of -mcpu and -march and make them with no interaction is a good idea. (behavior is equal to GCC)

In LLVM, if you add target-cpu metadata to a function (which is added by clang, based on -mcpu), that function will have all the features of that CPU automatically added to it (as if you had used -mattr with all the features in the model). If you don't add that metadata, a generic scheduling model will be chosen. This suggests at the moment there can be no separation between -mtune and -march as there is in GCC (without changes to the target-independent parts of LLVM).

[khchen]

update implementation and handle -mcpu with explicitly specified -march.
If -mcpu has default march, explicitly -march will overwrite it.

1. reference ARM/AArch64 and X86 to implement RISCVTargetParser.def
2. in clang, -mtune option alias to -mcpu. This patch supports -mtune option via -mcpu.
3. propose two category of CPUs in TargetParser and backend. First is similar gcc's -mtune option (it includes micro architecture related feature only, ex. rocket-rv32 has different schedule model), another also has default -march (isa string).
4. add two sifive cpu which has default -march
5. changed default march logic.

march: in order:

1. Explicit choices using -march
2. A default based on -mcpu, if target cpu has default -march
3. A default based on -mabi, if provided
4. A default based on the target triple's arch

I think it's also okay if we want to only support -mcpu which is similar to gcc's -mtune at the moment . Because in current implementation,
users can query available CPUs via -mcpu=? on clang but mcpu option is not workable.

[khchen]

@lenary (Sorry for the very late reply...)

In D71124#1829998, @lenary wrote:

In D71124#1792216, @khchen wrote:

The problem is how -mcpu interact with explicitly specified -march (or target features).

1. in GCC, -mcpu is only used to chose the pipeline model,

I think you mean "in GCC, -mtune is only used to choose the pipeline model" (-mcpu is not documented in the RISC-V specific GCC options documentation).

Yes, It's my mistake, I mean -mtune.

Clang should attempt to maintain compatibility with GCC flags, but if they only implement -mtune, then we have a little more freedom to do something ergonomic with -mcpu.

I'll note that clang already has a large TODO around implementing -mtune in general, though the AArch64 backend seems to support it for some option choices.

2. I also read this article talking about the X86 and ARM to handle those options.
   • -march=X: Tells the compiler that X is the minimal architecture the binary must run on. The compiler is free to use architecture-specific instructions. This flag behaves differently on Arm and x86. On Arm, -march does not override -mtune, but on x86 -march will override both -mtune and -mcpu.
   • -mtune=X: Tells the compiler to optimize for microarchitecture X but does not allow the compiler to change the ABI or make assumptions about available instructions. This flag has the more-or-less the same meaning on Arm and x86.
   • -mcpu=X: On Arm, this flag is a combination of -march and -mtune. It simultaneously specifies the target architecture and optimizes for a given microarchitecture. On x86 this flag is a deprecated synonym for -mtune.

So maybe it makes sense to treat those flags behaves differently on different target .

3. I also tried llc to specific -mcpu and -attr (similar to -march, target-feature) in ARM, -attr will over write the default target-feature in -mcpu.

on RISC-V, in sometime (or most?) we have same pipeline model but support different extension combination,

I don't believe this to be correct. lowRISC's Ibex has a completely different pipeline model to rocket, and there are countless other RISC-V cores with different pipeline characteristics, including out-of-order pipeline implementations like BOOM. I don't think we can favour one particular scheduling model (beyond the generic ones we already default to).

Yes, so lowRISC's Ibex need to use different pipleine model.
I mention it just because in SiFive, the same serial core can share the same schedule model, but they have different isa extension.

so I think maybe distinguishing the purpose of -mcpu and -march and make them with no interaction is a good idea. (behavior is equal to GCC)

In LLVM, if you add target-cpu metadata to a function (which is added by clang, based on -mcpu), that function will have all the features of that CPU automatically added to it (as if you had used -mattr with all the features in the model). If you don't add that metadata, a generic scheduling model will be chosen. This suggests at the moment there can be no separation between -mtune and -march as there is in GCC (without changes to the target-independent parts of LLVM).

thanks for reminding me, I re-implementation it.

In D71124#1829998, @lenary wrote:

In D71124#1792216, @khchen wrote:

The problem is how -mcpu interact with explicitly specified -march (or target features).

1. in GCC, -mcpu is only used to chose the pipeline model,

I think you mean "in GCC, -mtune is only used to choose the pipeline model" (-mcpu is not documented in the RISC-V specific GCC options documentation).

Clang should attempt to maintain compatibility with GCC flags, but if they only implement -mtune, then we have a little more freedom to do something ergonomic with -mcpu.

I'll note that clang already has a large TODO around implementing -mtune in general, though the AArch64 backend seems to support it for some option choices.

2. I also read this article talking about the X86 and ARM to handle those options.
   • -march=X: Tells the compiler that X is the minimal architecture the binary must run on. The compiler is free to use architecture-specific instructions. This flag behaves differently on Arm and x86. On Arm, -march does not override -mtune, but on x86 -march will override both -mtune and -mcpu.
   • -mtune=X: Tells the compiler to optimize for microarchitecture X but does not allow the compiler to change the ABI or make assumptions about available instructions. This flag has the more-or-less the same meaning on Arm and x86.
   • -mcpu=X: On Arm, this flag is a combination of -march and -mtune. It simultaneously specifies the target architecture and optimizes for a given microarchitecture. On x86 this flag is a deprecated synonym for -mtune.

So maybe it makes sense to treat those flags behaves differently on different target .

3. I also tried llc to specific -mcpu and -attr (similar to -march, target-feature) in ARM, -attr will over write the default target-feature in -mcpu.

on RISC-V, in sometime (or most?) we have same pipeline model but support different extension combination,

I don't believe this to be correct. lowRISC's Ibex has a completely different pipeline model to rocket, and there are countless other RISC-V cores with different pipeline characteristics, including out-of-order pipeline implementations like BOOM. I don't think we can favour one particular scheduling model (beyond the generic ones we already default to).

so I think maybe distinguishing the purpose of -mcpu and -march and make them with no interaction is a good idea. (behavior is equal to GCC)

In LLVM, if you add target-cpu metadata to a function (which is added by clang, based on -mcpu), that function will have all the features of that CPU automatically added to it (as if you had used -mattr with all the features in the model). If you don't add that metadata, a generic scheduling model will be chosen. This suggests at the moment there can be no separation between -mtune and -march as there is in GCC (without changes to the target-independent parts of LLVM).

[lenary]

This is looking good.

I remember we discussed this on the LLVM call a few weeks ago - there was a discussion as to whether we should be prioritising -march or -mcpu - do you recall the outcome of that discussion?

clang/lib/Basic/Targets/RISCV.cpp

166

It would be good to have /*Is64Bit=*/ before the boolean arguments to these functions.

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

501–516

What's the justification for removing this code?

clang/lib/Driver/ToolChains/CommonArgs.cpp

310

Should we be doing more validation here?

llvm/lib/Support/TargetParser.cpp

122

I think this should be prefixed RISCV, or moved into the RISCV namespace if you can?

259–260

It might be worth explicitly adding -64bit where FK_64BIT is not set.

[kito-cheng]

Another proposal for -mcpu and -mtune:

Decoupling the -mcpu and -mtune option, -mcpu only accept concrete CPU, and -mtune for micro-arch/pipeline model, they accept different option set.

e.g.
-mcpu=sifive-e24 # Imply -march=rv32imafc -mtune=sifive-2-series
-mtune=sifive-2-series # no effect on arch
-mtune=rocket # no effect on arch

So -mcpu=rocket is invalid, since it's micro-arch/pipeline model only,
and -mtune=sifive-e24 is invalid too, because it's CPU not a micro-arch.

[khchen]

address @lenary's review feedback

[khchen]

In D71124#2010759, @lenary wrote:

This is looking good.

I remember we discussed this on the LLVM call a few weeks ago - there was a discussion as to whether we should be prioritising -march or -mcpu - do you recall the outcome of that discussion?

Sorry, I don't remember the outcome of discussion...
I thought it make sense if both mcpu and march are specified, and march extensions overrides the mcpu extension
This also allows users to specific superset or subset of march.

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

501–516

I changed the logic in how to get the default march by calling getRISCVArch(Args, Triple);
getRISCVArch can also get the default march based on the triple, so we don't need above code now.

clang/lib/Driver/ToolChains/CommonArgs.cpp

310

I think we don't need to validation here, we have validation in RISCVTargetInfo::isValidCPUName. You can see it work in test/Driver/riscv-cpus.c#L22.

[khchen]

In D71124#2012090, @kito-cheng wrote:

Another proposal for -mcpu and -mtune:

Decoupling the -mcpu and -mtune option, -mcpu only accept concrete CPU, and -mtune for micro-arch/pipeline model, they accept different option set.

e.g.
-mcpu=sifive-e24 # Imply -march=rv32imafc -mtune=sifive-2-series
-mtune=sifive-2-series # no effect on arch
-mtune=rocket # no effect on arch

So -mcpu=rocket is invalid, since it's micro-arch/pipeline model only,
and -mtune=sifive-e24 is invalid too, because it's CPU not a micro-arch.

I agree this is better proposal but clang treats -mtune and -mcpu as same options now...
ex. https://github.com/llvm-mirror/clang/blob/master/include/clang/Driver/Options.td#L2751-L2752

[kito-cheng]

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

478

I think it worth to keep this comment untouched, since it describing GCC's behavior.

531

This part seems like is describing about GCC's behavior, so it should not change unless GCC changed?

[khchen]

address kito's comment

[lenary]

I realise this is almost certainly something we want to land before the LLVM 11 branch date, as we included schedules in LLVM 10 with no way to use them, and would like users to be able to use them. I'll bring it up on the call tomorrow - I hope this PR implements what we agreed from the previous calls.

[asb]

This has been hanging around for a while, but I think we'd basically agreed this is the right logic. The comments have ended up referring to flags that don't exist on Clang making it a little hard to follow, and I've added a request to slightly expand testing. If you make those cleanups I think it should be ready for a final review and merge.

As Sam says, lets flag this in today's RISC-V LLVM call to double-check everyone is happy.

EDIT: this patch also needs a rebase

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

540

As clang has no with-arch or with-abi, this comment seems inaccurate?

clang/test/Driver/riscv-cpus.c

3

I think for completeness this test should be validating the interaction of the ABI choosing logic with CPU selection as well. With the implemented logic I believe it should show that lp64d is selected for -mcpu=sifive-u54 and that -mcpu=sifive-u54 -mabi=lp64 will respect the ABI choice

[khchen]

BTW, this patch depends on D77030, which aim to avoid the forcing of any ProcessorModel to have FeatureRVCHints feature.
But if we decide to keep the FeatureRVCHints, I need to change implementation a little.

clang/test/Driver/riscv-cpus.c

3

okay, it makes sense to me, I will update this patch soon.

[khchen]

addess @asb 's comment.

[RISCV][Clang] Support -mcpu option.

Summary:

1. gcc uses -march and -mtune flag to chose arch and

pipeline model, but clang does not have -mtune flag,
we uses -mcpu to chose both info.

2. Add SiFive e31 and u54 cpu which have default march

and pipeline model.

3. Specific -mcpu with rocket-rv[32|64] would select

pipeline model only, and use the driver's arch choosing
logic to get default arch.

[khchen]

fix typo

[khchen]

avoid to check compiler version in testcase

[khchen]

@asb @lenary I thought this path is ready to land?

[lenary]

I've got one major issue (inline below), and I'm confused by some other behaviour:

When I run clang --target=riscv64 -mcpu=?, the list includes both generic-rv32 and generic-rv64. It doesn't show only the 64-bit cpus. This is not changed by giving a full triple, or by additionally specifying -march=rv64gc. Should it be?

For instance, this output:

$ clang --target=riscv64-unknown-elf -mcpu=\? -march=rv64gc
clang version 11.0.0
Target: riscv64-unknown-unknown-elf
Thread model: posix
InstalledDir: /home/selliott/llvm-project/./build/llvm_clang/all/bin
Available CPUs for this target:

	generic-rv32
	generic-rv64
	rocket-rv32
	rocket-rv64
	sifive-e31
	sifive-u54

Use -mcpu or -mtune to specify the target's processor.
For example, clang --target=aarch64-unknown-linux-gui -mcpu=cortex-a35

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

512

I now get a stacktrace here if I call clang --target=riscv32 -march=unknown foo.c -c. In clang-10, you get a nice error:

clang-10: error: invalid arch name 'wat', string must begin with rv32{i,e,g} or rv64{i,g}

The stacktrace is coming from the call to getRISCVABI in findRISCVBareMetalMultilibs (in clang/lib/Driver/ToolChains/Gnu.cpp:1608).

[khchen]

Hi @lenary
This is normal behavior in current clang implementation,
-mcpu=? flag does not interact with any flags, it just print out the all of ProcessorModel registered in backend.
https://github.com/llvm/llvm-project/blob/master/clang/tools/driver/cc1_main.cpp#L213-L215

You can reference this, so the clang -mcpu=? result is exactly equal to ./bin/llc -mattr=+cpuhelp.

./bin/llc -mattr=+cpuhelp  foo.ll  --mtriple=riscv32
Available CPUs for this target:

        generic-rv32
        generic-rv64
        rocket-rv32
        rocket-rv64

Use -mcpu or -mtune to specify the target's processor.
For example, clang --target=aarch64-unknown-linux-gui -mcpu=cortex-a35

You can try clang -mcpu=? --target=mips64el or other target too.

But you are right, this behavior is very confusing users.

In D71124#2150535, @lenary wrote:

I've got one major issue (inline below), and I'm confused by some other behaviour:

When I run clang --target=riscv64 -mcpu=?, the list includes both generic-rv32 and generic-rv64. It doesn't show only the 64-bit cpus. This is not changed by giving a full triple, or by additionally specifying -march=rv64gc. Should it be?

For instance, this output:

$ clang --target=riscv64-unknown-elf -mcpu=\? -march=rv64gc
clang version 11.0.0
Target: riscv64-unknown-unknown-elf
Thread model: posix
InstalledDir: /home/selliott/llvm-project/./build/llvm_clang/all/bin
Available CPUs for this target:

	generic-rv32
	generic-rv64
	rocket-rv32
	rocket-rv64
	sifive-e31
	sifive-u54

Use -mcpu or -mtune to specify the target's processor.
For example, clang --target=aarch64-unknown-linux-gui -mcpu=cortex-a35

[asb]

I've added some suggestions to clarify the code comments. I think before landing it would be good to address the crash Sam pointed out for an invalid -march, but otherwise I think this looks good to me (at least, it seems worth landing this and if further issues crop up we can fix them and request them for merging into the LLVM 11 branch).

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

476

"The logic used in GCC 9.2.0 i the following, in order:"

485

"Clang uses the following logic;"

488

"A default based on the architecture as determined by getRISCVArch"

489

"Choose a default based on the target architecture"

527

"The logic used in GCC 9.2.0 is the following, in order:"

540

Based on -mcpu if the target CPU has a default ISA string

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

29

These functions aren't defined anywhere - delete?

[khchen]

address @asb's comment. thanks.

Thanks for @lenary bug report.
I cannot reproduce the crash in local,
but I though the problem is cause by removing "Choose a default based on the triple" logic in getRISCVABI
The MArch value is "unknown" and there is no return value which can match any conditionin.
so I add it back and also update the "invalid arch name" test.

[lenary]

Thanks for the fix!

Please can you also update clang/test/Misc/target-invalid-cpu-note.c for riscv32 and riscv64 - it's likely you'll need the fix in the inline note below.

Also, there are a bunch of clang-tidy issues, which I think we can fix now rather than later.

llvm/lib/Support/TargetParser.cpp

263

This line should be if (C.Kind != CK_INVALID && IsRV64 == C.Is64Bit()) so that when clang prints out valid CPUs, 'invalid' is not included in the list.

[khchen]

address @lenary's comment, good catch! thanks a lot!!

[lenary]

I am happy with this. I think we should get it landed so we can backport it to the LLVM 11 branch.

I don't know if any of @asb's comments are unresolved. You should probably wait for his OK too.

[asb]

LGTM, thanks!

[oceanfish81]

I tried to build the following:

https://gist.github.com/advancedwebdeveloper/09033869445a09a2e297a73387d46c41/raw/bf7dac33e256621c445f9e61f88a832e50d901a3/llvm_cpu_features_investigation.cpp

but it didn't show me any CPU features, on https://fedoraproject.org/wiki/Architectures/RISC-V/Installing#Boot_under_QEMU

[khchen]

In D71124#2415424, @oceanfish81 wrote:

I tried to build the following:

https://gist.github.com/advancedwebdeveloper/09033869445a09a2e297a73387d46c41/raw/bf7dac33e256621c445f9e61f88a832e50d901a3/llvm_cpu_features_investigation.cpp

but it didn't show me any CPU features, on https://fedoraproject.org/wiki/Architectures/RISC-V/Installing#Boot_under_QEMU

It seems getHostCPUFeatures does not support RISCV target.

[oceanfish81]

@khchen , what is the recomended way to get the current CPU features?

I see that there are some ISA extensions defined here .

So RISC-V back-end has another API, for both identifying available CPU (or vCPU, if under Qemu) features?
How does the CLI options correspond with the back-end capabilities?

There is some code, for gollvm project https://go.googlesource.com/gollvm/+/e3ede8ef8009429eaae91bbae2d67542ddaa5853/tools/capture-fcn-attributes.go - and it relies on https://github.com/llvm/llvm-project/blob/48ddf5e182c61cb93d66325f5690312d9e9226eb/llvm/lib/Support/Host.cpp (auto-generation).
I need to understand whethershould Host.cpp be patched or should I use an arch. specific/dedicated workaround.

I am forcasting sgnificant contrast in gollvm's adoption, between various RISC-V boards, since of an active usage of different CPU features (available on one micro-controller, with others unavailable - and vice versa).

[khchen]

How does the CLI options correspond with the back-end capabilities?

clang -print-supported-cpus

[oceanfish81]

@khchen ,
how should I obtain available (v)CPU features?
Any sample code, that should work on RISC-V?

[jrtc27]

In D71124#2423633, @oceanfish81 wrote:

@khchen ,
how should I obtain available (v)CPU features?
Any sample code, that should work on RISC-V?

Probably getauxval(AT_HWCAP); both Linux and FreeBSD put the ISA string in the low 26 bits in the same vein as misa.

clang/lib/Basic/Targets/RISCV.h

 #include "llvm/Support/Compiler.h"
 
 namespace clang {
 namespace targets {
 
 // RISC-V Target
 class RISCVTargetInfo : public TargetInfo {
 protected:
-  std::string ABI;
+  std::string ABI, CPU;
   bool HasM;
   bool HasA;
   bool HasF;
   bool HasD;
   bool HasC;
 
 public:
   RISCVTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
       : TargetInfo(Triple), HasM(false), HasA(false), HasF(false),
         HasD(false), HasC(false) {
     LongDoubleWidth = 128;
     LongDoubleAlign = 128;
     LongDoubleFormat = &llvm::APFloat::IEEEquad();
     SuitableAlign = 128;
     WCharType = SignedInt;
     WIntType = UnsignedInt;
   }
 
+  bool setCPU(const std::string &Name) override {
+    if (!isValidCPUName(Name))
+      return false;
+    CPU = Name;
+    return true;
+  }
+
   StringRef getABI() const override { return ABI; }
   void getTargetDefines(const LangOptions &Opts,
                         MacroBuilder &Builder) const override;
 
   ArrayRef<Builtin::Info> getTargetBuiltins() const override { return None; }
 
   BuiltinVaListKind getBuiltinVaListKind() const override {
     return TargetInfo::VoidPtrBuiltinVaList;
public:
   bool setABI(const std::string &Name) override {
     if (Name == "ilp32" || Name == "ilp32f" || Name == "ilp32d") {
       ABI = Name;
       return true;
     }
     return false;
   }
 
+  bool isValidCPUName(StringRef Name) const override;
+  void fillValidCPUList(SmallVectorImpl<StringRef> &Values) const override;
+
   void setMaxAtomicWidth() override {
     MaxAtomicPromoteWidth = 128;
 
     if (HasA)
       MaxAtomicInlineWidth = 32;
   }
 };
 class LLVM_LIBRARY_VISIBILITY RISCV64TargetInfo : public RISCVTargetInfo {
 public:
   RISCV64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
       : RISCVTargetInfo(Triple, Opts) {
     LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
     IntMaxType = Int64Type = SignedLong;
     resetDataLayout("e-m:e-p:64:64-i64:64-i128:128-n64-S128");
   }
 
   bool setABI(const std::string &Name) override {
     if (Name == "lp64" || Name == "lp64f" || Name == "lp64d") {
       ABI = Name;
       return true;
     }
     return false;
   }
 
+  bool isValidCPUName(StringRef Name) const override;
+  void fillValidCPUList(SmallVectorImpl<StringRef> &Values) const override;
+
   void setMaxAtomicWidth() override {
     MaxAtomicPromoteWidth = 128;
 
     if (HasA)
       MaxAtomicInlineWidth = 64;
   }
 };
 } // namespace targets
 } // namespace clang
 
 #endif // LLVM_CLANG_LIB_BASIC_TARGETS_RISCV_H

clang/lib/Basic/Targets/RISCV.cpp

 //===--- RISCV.cpp - Implement RISCV target feature support ---------------===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 //
 // This file implements RISCV TargetInfo objects.
 //
 //===----------------------------------------------------------------------===//
 
 #include "RISCV.h"
 #include "clang/Basic/MacroBuilder.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/Support/TargetParser.h"
 
 using namespace clang;
 using namespace clang::targets;
 
 ArrayRef<const char *> RISCVTargetInfo::getGCCRegNames() const {
   static const char *const GCCRegNames[] = {
       // Integer registers
       "x0",  "x1",  "x2",  "x3",  "x4",  "x5",  "x6",  "x7",
for (const auto &Feature : Features) {
     else if (Feature == "+d")
       HasD = true;
     else if (Feature == "+c")
       HasC = true;
   }
 
   return true;
 }
+
+bool RISCV32TargetInfo::isValidCPUName(StringRef Name) const {
+  return llvm::RISCV::checkCPUKind(llvm::RISCV::parseCPUKind(Name), false);
+}
+
+void RISCV32TargetInfo::fillValidCPUList(
+    SmallVectorImpl<StringRef> &Values) const {
+  llvm::RISCV::fillValidCPUArchList(Values, false);
+}
+
+bool RISCV64TargetInfo::isValidCPUName(StringRef Name) const {
+  return llvm::RISCV::checkCPUKind(llvm::RISCV::parseCPUKind(Name), true);
+}
+
+void RISCV64TargetInfo::fillValidCPUList(
+    SmallVectorImpl<StringRef> &Values) const {
+  llvm::RISCV::fillValidCPUArchList(Values, true);
+}

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

 namespace riscv {
 void getRISCVTargetFeatures(const Driver &D, const llvm::Triple &Triple,
                             const llvm::opt::ArgList &Args,
                             std::vector<llvm::StringRef> &Features);
 StringRef getRISCVABI(const llvm::opt::ArgList &Args,
                       const llvm::Triple &Triple);
 StringRef getRISCVArch(const llvm::opt::ArgList &Args,
                        const llvm::Triple &Triple);
+StringRef getMArchFromMabi(StringRef MABI);
+StringRef getMArchFromTriple(const llvm::Triple &Triple);
 } // end namespace riscv
 } // namespace tools
 } // end namespace driver
 } // end namespace clang
 
 #endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_ARCH_RISCV_H

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

static bool getArchFeatures(const Driver &D, StringRef MArch,
   // TODO: It is illegal to specify 'e' extensions with 'f' and 'd'.
 
   // Handle all other types of extensions.
   getExtensionFeatures(D, Args, Features, MArch, OtherExts);
 
   return true;
 }
 
+// Get features except standard extension feature
+void getRISCFeaturesFromMcpu(const Driver &D, const llvm::Triple &Triple,
+                             const llvm::opt::ArgList &Args,
+                             const llvm::opt::Arg *A, StringRef Mcpu,
+                             std::vector<StringRef> &Features) {
+  bool Is64Bit = (Triple.getArch() == llvm::Triple::riscv64);
+  llvm::RISCV::CPUKind CPUKind = llvm::RISCV::parseCPUKind(Mcpu);
+  if (!llvm::RISCV::checkCPUKind(CPUKind, Is64Bit) ||
+      !llvm::RISCV::getCPUFeaturesExceptStdExt(CPUKind, Features)) {
+    D.Diag(clang::diag::err_drv_clang_unsupported) << A->getAsString(Args);
+  }
+}
+
 void riscv::getRISCVTargetFeatures(const Driver &D, const llvm::Triple &Triple,
                                    const ArgList &Args,
                                    std::vector<StringRef> &Features) {
   StringRef MArch = getRISCVArch(Args, Triple);
 
   if (!getArchFeatures(D, MArch, Features, Args))
     return;
 
+  // If users give march and mcpu, get std extension feature from MArch
+  // and other features (ex. mirco architecture feature) from mcpu
+  if (Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
+    getRISCFeaturesFromMcpu(D, Triple, Args, A, A->getValue(), Features);
+
   // Handle features corresponding to "-ffixed-X" options
   if (Args.hasArg(options::OPT_ffixed_x1))
     Features.push_back("+reserve-x1");
   if (Args.hasArg(options::OPT_ffixed_x2))
     Features.push_back("+reserve-x2");
   if (Args.hasArg(options::OPT_ffixed_x3))
     Features.push_back("+reserve-x3");
   if (Args.hasArg(options::OPT_ffixed_x4))
assert((Triple.getArch() == llvm::Triple::riscv32 ||
          "Unexpected triple");
 
   // GCC's logic around choosing a default `-mabi=` is complex. If GCC is not
   // configured using `--with-abi=`, then the logic for the default choice is
   // defined in config.gcc. This function is based on the logic in GCC 9.2.0. We
   // deviate from GCC's default only on baremetal targets (UnknownOS) where
   // neither `-march` nor `-mabi` is specified.
   //
   // The logic uses the following, in order:
   // 1. Explicit choices using `--with-abi=`
-  // 2. A default based on `--with-arch=`, if provided
-  // 3. A default based on the target triple's arch
+  // 2. A default based on arch
   //
   // The logic in config.gcc is a little circular but it is not inconsistent.
   //
   // Clang does not have `--with-arch=` or `--with-abi=`, so we use `-march=`
   // and `-mabi=` respectively instead.
 
   // 1. If `-mabi=` is specified, use it.
   if (const Arg *A = Args.getLastArg(options::OPT_mabi_EQ))
     return A->getValue();
 
-  // 2. Choose a default based on `-march=`
+  // 2. Choose a default based on arch
   //
   // rv32g | rv32*d -> ilp32d
   // rv32e -> ilp32e
   // rv32* -> ilp32
   // rv64g | rv64*d -> lp64d
   // rv64* -> lp64
-  if (const Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
-    StringRef MArch = A->getValue();
+  StringRef MArch = getRISCVArch(Args, Triple);
 
-    if (MArch.startswith_lower("rv32")) {
-      // FIXME: parse `March` to find `D` extension properly
-      if (MArch.substr(4).contains_lower("d") ||
-          MArch.startswith_lower("rv32g"))
-        return "ilp32d";
-      else if (MArch.startswith_lower("rv32e"))
-        return "ilp32e";
-      else
-        return "ilp32";
-    } else if (MArch.startswith_lower("rv64")) {
-      // FIXME: parse `March` to find `D` extension properly
-      if (MArch.substr(4).contains_lower("d") ||
-          MArch.startswith_lower("rv64g"))
-        return "lp64d";
-      else
-        return "lp64";
-    }
-  }
+    if (MArch.substr(4).contains_lower("d") || MArch.startswith_lower("rv32g"))
+    if (MArch.substr(4).contains_lower("d") || MArch.startswith_lower("rv64g"))
 
-  // 3. Choose a default based on the triple
-  //
-  // We deviate from GCC's defaults here:
-  // - On `riscv{XLEN}-unknown-elf` we use the integer calling convention only.
-  // - On all other OSs we use the double floating point calling convention.
-  if (Triple.getArch() == llvm::Triple::riscv32) {
-    if (Triple.getOS() == llvm::Triple::UnknownOS)
-      return "ilp32";
-    else
-      return "ilp32d";
-  } else {
-    if (Triple.getOS() == llvm::Triple::UnknownOS)
-      return "lp64";
-    else
-      return "lp64d";
-  }
-}
-
 StringRef riscv::getRISCVArch(const llvm::opt::ArgList &Args,
                               const llvm::Triple &Triple) {
   assert((Triple.getArch() == llvm::Triple::riscv32 ||
           Triple.getArch() == llvm::Triple::riscv64) &&
          "Unexpected triple");
 
   // GCC's logic around choosing a default `-march=` is complex. If GCC is not
   // configured using `--with-arch=`, then the logic for the default choice is
   // defined in config.gcc. This function is based on the logic in GCC 9.2.0. We
   // deviate from GCC's default only on baremetal targets (UnknownOS) where
   // neither `-march` nor `-mabi` is specified.
   //
   // The logic uses the following, in order:
   // 1. Explicit choices using `--with-arch=`
-  // 2. A default based on `--with-abi=`, if provided
-  // 3. A default based on the target triple's arch
+  // 2. Based on `-mcpu` if target cpu has default isa extension feature
+  // 3. A default based on `--with-abi=`, if provided
+  // 4. A default based on the target triple's arch
   //
   // The logic in config.gcc is a little circular but it is not inconsistent.
   //
   // Clang does not have `--with-arch=` or `--with-abi=`, so we use `-march=`
   // and `-mabi=` respectively instead.
   //
   // Clang does not yet support MULTILIB_REUSE, so we use `rv{XLEN}imafdc`
   // instead of `rv{XLEN}gc` though they are (currently) equivalent.
 
   // 1. If `-march=` is specified, use it.
   if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
     return A->getValue();
 
-  // 2. Choose a default based on `-mabi=`
+  // 2. Get march (isa string) based on `-mcpu=`
+  if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ)) {
+    StringRef MArch = llvm::RISCV::getMArchFromMcpu(A->getValue());
+    // Bypass if target cpu's default march is empty.
+    if (MArch != "")
+      return MArch;
+  }
+
+  // 3. Choose a default based on `-mabi=`
   //
   // ilp32e -> rv32e
   // ilp32 | ilp32f | ilp32d -> rv32imafdc
   // lp64 | lp64f | lp64d -> rv64imafdc
   if (const Arg *A = Args.getLastArg(options::OPT_mabi_EQ)) {
     StringRef MABI = A->getValue();
 
     if (MABI.equals_lower("ilp32e"))
       return "rv32e";
     else if (MABI.startswith_lower("ilp32"))
       return "rv32imafdc";
     else if (MABI.startswith_lower("lp64"))
       return "rv64imafdc";
   }
 
-  // 3. Choose a default based on the triple
+  // 4. Choose a default based on the triple
   //
   // We deviate from GCC's defaults here:
   // - On `riscv{XLEN}-unknown-elf` we default to `rv{XLEN}imac`
   // - On all other OSs we use `rv{XLEN}imafdc` (equivalent to `rv{XLEN}gc`)
   if (Triple.getArch() == llvm::Triple::riscv32) {
     if (Triple.getOS() == llvm::Triple::UnknownOS)
       return "rv32imac";
     else
       return "rv32imafdc";
   } else {
     if (Triple.getOS() == llvm::Triple::UnknownOS)
       return "rv64imac";
     else
       return "rv64imafdc";
   }
 }

clang/lib/Driver/ToolChains/CommonArgs.cpp

if (TargetCPUName.empty() && !T.isOSDarwin()) {
         TargetCPUName = "ppc64";
       else if (T.getArch() == llvm::Triple::ppc64le)
         TargetCPUName = "ppc64le";
       else
         TargetCPUName = "ppc";
     }
     return TargetCPUName;
   }
+  case llvm::Triple::riscv32:
+  case llvm::Triple::riscv64:
+    if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
+      return A->getValue();
+    return "";
 
   case llvm::Triple::bpfel:
   case llvm::Triple::bpfeb:
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::sparcv9:
     if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
       return A->getValue();

clang/test/Driver/riscv-cpus.c

+// Check target CPUs are correctly passed.
+
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=rocket-rv32 | FileCheck -check-prefix=MCPU-ROCKETCHIP32 %s
+// MCPU-ROCKETCHIP32: "-nostdsysteminc" "-target-cpu" "rocket-rv32"
+
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=rocket-rv64 | FileCheck -check-prefix=MCPU-ROCKETCHIP64 %s
+// MCPU-ROCKETCHIP64: "-nostdsysteminc" "-target-cpu" "rocket-rv64"
+// MCPU-ROCKETCHIP64: "-target-feature" "+64bit"
+
+// mcpu with default march
+// RUN: %clang -target riscv64 -### -c %s 2>&1 -mcpu=sifive-u54 | FileCheck -check-prefix=MCPU-SIFIVE-U54 %s
+// MCPU-SIFIVE-U54: "-nostdsysteminc" "-target-cpu" "sifive-u54"
+// MCPU-SIFIVE-U54: "-target-feature" "+m" "-target-feature" "+a" "-target-feature" "+f" "-target-feature" "+d"
+// MCPU-SIFIVE-U54: "-target-feature" "+c" "-target-feature" "+64bit"
+
+// march overwirte mcpu's default march
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=sifive-e31 -march=rv32imc | FileCheck -check-prefix=MCPU-MARCH %s
+// MCPU-MARCH: "-nostdsysteminc" "-target-cpu" "sifive-e31" "-target-feature" "+m" "-target-feature" "+c"
+
+// Check failed cases
+
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=generic-rv321 | FileCheck -check-prefix=FAIL-MCPU-NAME %s
+// FAIL-MCPU-NAME: clang-11: error: the clang compiler does not support '-mcpu=generic-rv321'
+
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=generic-rv32 -march=rv64i | FileCheck -check-prefix=MISMATCH-ARCH %s
+// MISMATCH-ARCH: clang-11: error: the clang compiler does not support '-mcpu=generic-rv32'
+
+// RUN: %clang -target riscv32 -### -c %s 2>&1 -mcpu=generic-rv64 | FileCheck -check-prefix=MISMATCH-MCPU %s
+// MISMATCH-MCPU: clang-11: error: the clang compiler does not support '-mcpu=generic-rv64'

llvm/include/llvm/Support/RISCVTargetParser.def

+#ifndef PROC
+#define PROC(ENUM, NAME, FEATURES, DEFAULT_MARCH)
+#endif
+
+PROC(INVALID, {"invalid"}, FK_INVALID, {""})
+PROC(GENERIC_RV32, {"generic-rv32"}, FK_NONE, {""})
+PROC(GENERIC_RV64, {"generic-rv64"}, FK_64BIT, {""})
+PROC(ROCKET_RV32, {"rocket-rv32"}, FK_NONE, {""})
+PROC(ROCKET_RV64, {"rocket-rv64"}, FK_64BIT, {""})
+PROC(SIFIVE_E31, {"sifive-e31"}, FK_NONE, {"rv32imac"})
+PROC(SIFIVE_U54, {"sifive-u54"}, FK_64BIT, {"rv64gc"})
+
+#undef PROC

llvm/include/llvm/Support/TargetParser.h

 
 void fillValidArchListAMDGCN(SmallVectorImpl<StringRef> &Values);
 void fillValidArchListR600(SmallVectorImpl<StringRef> &Values);
 
 IsaVersion getIsaVersion(StringRef GPU);
 
 } // namespace AMDGPU
 
+namespace RISCV {
+
+enum CPUKind : unsigned {
+#define PROC(ENUM, NAME, FEATURES, DEFAULT_MARCH) CK_##ENUM,
+#include "RISCVTargetParser.def"
+};
+
+enum FeatureKind : unsigned {
+  FK_INVALID = 0,
+  FK_NONE = 1,
+  FK_STDEXTM = 1 << 2,
+  FK_STDEXTA = 1 << 3,
+  FK_STDEXTF = 1 << 4,
+  FK_STDEXTD = 1 << 5,
+  FK_STDEXTC = 1 << 6,
+  FK_64BIT = 1 << 7,
+};
+
+bool checkCPUKind(CPUKind kind, bool IsRV64);
+CPUKind parseCPUKind(StringRef CPU);
+StringRef getMArchFromMcpu(StringRef CPU);
+void fillValidCPUArchList(SmallVectorImpl<StringRef> &Values, bool IsRV64);
+bool getCPUFeaturesExceptStdExt(CPUKind kind, std::vector<StringRef> &Features);
+
+} // namespace RISCV
+
 } // namespace llvm
 
 #endif

llvm/lib/Support/TargetParser.cpp

 //===-- TargetParser - Parser for target features ---------------*- C++ -*-===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 //
 // This file implements a target parser to recognise hardware features such as
 // FPU/CPU/ARCH names as well as specific support such as HDIV, etc.
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/TargetParser.h"
+#include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Twine.h"
 
 using namespace llvm;
 using namespace AMDGPU;
+using namespace RISCV;
 
 namespace {
 
 struct GPUInfo {
   StringLiteral Name;
   StringLiteral CanonicalName;
   AMDGPU::GPUKind Kind;
   unsigned Features;
[](const GPUInfo &A, const GPUInfo &B) {
       return A.Kind < B.Kind;
     });
 
   if (I == Table.end())
     return nullptr;
   return I;
 }
 
+struct CPUInfo {
+  StringLiteral Name;
+  CPUKind Kind;
+  unsigned Features;
+  StringLiteral DefaultMarch;
+  bool Is64Bit() const { return (Features & FK_64BIT); }
+};
+
+constexpr CPUInfo RISCVCPUInfo[] = {
+#define PROC(ENUM, NAME, FEATURES, DEFAULT_MARCH)                     \
+  {NAME, CK_##ENUM, FEATURES, DEFAULT_MARCH},
+#include "llvm/Support/RISCVTargetParser.def"
+};
+
 } // namespace
 
 StringRef llvm::AMDGPU::getArchNameAMDGCN(GPUKind AK) {
   if (const auto *Entry = getArchEntry(AK, AMDGCNGPUs))
     return Entry->CanonicalName;
   return "";
 }
 
AMDGPU::IsaVersion AMDGPU::getIsaVersion(StringRef GPU) {
   case GK_GFX908:  return {9, 0, 8};
   case GK_GFX909:  return {9, 0, 9};
   case GK_GFX1010: return {10, 1, 0};
   case GK_GFX1011: return {10, 1, 1};
   case GK_GFX1012: return {10, 1, 2};
   default:         return {0, 0, 0};
   }
 }
+
+bool RISCV::checkCPUKind(CPUKind Kind, bool IsRV64) {
+  if (Kind == CK_INVALID)
+    return false;
+  return RISCVCPUInfo[static_cast<unsigned>(Kind)].Is64Bit() == IsRV64;
+}
+
+RISCV::CPUKind RISCV::parseCPUKind(StringRef CPU) {
+  return llvm::StringSwitch<CPUKind>(CPU)
+#define PROC(ENUM, NAME, FEATURES, DEFAULT_MARCH) .Case(NAME, CK_##ENUM)
+#include "llvm/Support/RISCVTargetParser.def"
+      .Default(CK_INVALID);
+}
+
+StringRef RISCV::getMArchFromMcpu(StringRef CPU) {
+  CPUKind Kind = parseCPUKind(CPU);
+  return RISCVCPUInfo[static_cast<unsigned>(Kind)].DefaultMarch;
+}
+
+void RISCV::fillValidCPUArchList(SmallVectorImpl<StringRef> &Values, bool IsRV64) {
+  for (const auto &C : RISCVCPUInfo) {
+    if (IsRV64 == C.Is64Bit())
+      Values.emplace_back(C.Name);
+  }
+}
+
+// Get all features except standard extension feature
+bool RISCV::getCPUFeaturesExceptStdExt(CPUKind Kind,
+                                       std::vector<StringRef> &Features) {
+  unsigned features = RISCVCPUInfo[static_cast<unsigned>(Kind)].Features;
+
+  if (features == FK_INVALID)
+    return false;
+
+  if (features & FK_64BIT)
+    Features.push_back("+64bit");
+
+  return true;
+}

llvm/lib/Target/RISCV/RISCV.td

 def : ProcessorModel<"generic-rv32", NoSchedModel, []>;
 
 def : ProcessorModel<"generic-rv64", NoSchedModel, [Feature64Bit]>;
 
 def : ProcessorModel<"rocket-rv32", Rocket32Model, []>;
 
 def : ProcessorModel<"rocket-rv64", Rocket64Model, [Feature64Bit]>;
 
+def : ProcessorModel<"sifive-e31", Rocket32Model, [FeatureStdExtM,
+                                                   FeatureStdExtA,
+                                                   FeatureStdExtC]>;
+
+def : ProcessorModel<"sifive-u54", Rocket64Model, [Feature64Bit,
+                                                   FeatureStdExtM,
+                                                   FeatureStdExtA,
+                                                   FeatureStdExtF,
+                                                   FeatureStdExtD,
+                                                   FeatureStdExtC]>;
 
 //===----------------------------------------------------------------------===//
 // Define the RISC-V target.
 //===----------------------------------------------------------------------===//
 
 def RISCVInstrInfo : InstrInfo {
   let guessInstructionProperties = 0;
 }