There are some instructions that my processor does not support. How can I prevent gcc from using these instructions?

[LiHao217]

There are some instructions that my processor does not support. How can I prevent gcc from using these instructions?

I designed a simple riscv processor, which has very few instructions, only a dozen. How can I make gcc compile Mini Program with only a few instructions I have? I tried to delete instructions that I did not design in riscv.md, but without success.

[LiHao217]

@jim-wilson Hello, I've come to ask you again. Do you know what I should do? thank you very much.

[aswaterman]

We designed RV32I so that there's no good reason to omit any of the instructions. If you want to omit some of the instructions in RV32I, you'll need to modify the compiler yourself. We can't support you in that effort. Honestly, it's much less effort to just implement all of the instructions in RV32I. And in nearly all cases, the result will have better PPA characteristics.

[LiHao217]

Well, I guess I'll have to modify the gcc myself. What am I supposed to do? Apart from deleting instructions in gcc's riscv.md, what else do I need to do? @aswaterman

[aswaterman]

Many of the instructions in RV32I are essential for code generation. Removing the instructions from the machine description is the first step, but the subsequent steps might take dozens of hours of work for an experienced GCC hacker.

It will be much, much easier to enhance your processor to support all of RV32I than it will be to modify GCC.

I'm going to close this issue, because it is beyond the scope of what we can support here.

[jim-wilson]

Like Andrew mentioned, a lot of the patterns are required for the compiler to work. You can try disabling patterns you don't need, but you might need to add alternative definitions for the pattern if they are part of the required set. This is likely to be a significant amount of work. You can also try adding abort() calls to patterns you don't want, and if you hit the abort, you will need to add an alternate pattern, if you don't hit the abort you are OK.

An easy way to disable a pattern is to add 0 to the condition. The condition is inside the first set of double quote characters. For instance there is a mulsi3 pattern that has "TARGET_MUL" if you change that to "0 && TARGET_MUL" then the pattern will be disabled always. This one can actually be turned off if you don't have the m extension, but this is just an example to show how to disable patterns.

[NazerkeT]

Hi there, Actually, I have a pretty similar issue with GCC and implementing Bitmanip. For the present, I have only implemented Zbb, Zbe, Zbs, Zbp groups for Ariane Core and want to test my current implementation, benchmarking is also a purpose. Given this situation, is it possible to prevent GCC from using Zbt, Zbm, Zbr, Zbc, Zbf instructions? Or anyways I have to implement full version? @aswaterman @jim-wilson

Thanks,

[aswaterman]

It's impractical for us to support code generation for arbitrary combinations of instructions. If you read Jim's previous post, he provides a recipe to hack the compiler to remove instructions.

[NazerkeT]

It's impractical for us to support code generation for arbitrary combinations of instructions. If you read Jim's previous post, he provides a recipe to hack the compiler to remove instructions.

Sure, I got the point, just wanted to clarify :)

An easy way to disable a pattern is to add 0 to the condition. The condition is inside the first set of double quote characters. For instance there is a mulsi3 pattern that has "TARGET_MUL" if you change that to "0 && TARGET_MUL" then the pattern will be disabled always. This one can actually be turned off if you don't have the m extension, but this is just an example to show how to disable patterns.

Following this advice from Jim's previous post, is it enough to disable the pattern in that way only? Or is there any other troubleshoots? I am really sorry for these naive questions, just this is my first RISCV and CPU related project, and I lack some background and experience :)

By the way, I have found this #166 , what do you think about that? As long as my instructions are implemented in subgroups manner, I think that could work for me, am I right?

Thanks, Regards,

[aswaterman]

For most optional instructions, like those in the Zb* extensions, Jim's suggestion will suffice. If you try doing the 0 && thing for crucial instructions, e.g. add, it'll break the compiler. But it'll probably suffice for your purposes.

If we need to solve this problem in the long term, the #166 approach is reasonable. But for any experimental purposes, it's better just to hack it.

[NazerkeT]

Okay, got it, thank you very much!

[NazerkeT]

I am sorry, by the way, is there any similar hacking for riscv-binutils-gdb? @aswaterman

Thanks Best regards,

[aswaterman]

What's your goal, exactly? If you're just trying to evaluate the efficacy of the various instructions for compiled code, then there's no need to hack binutils, spike, etc. It's harmless if they support extra instructions that you don't actually use.

[NazerkeT]

Yes, my goal is to test the core for efficacy with implemented instruction groups. Now, I see the point, thanks!

Best wishes,