Bitmanip support

[imphil]

We are making fast progress on implementing the B extension on Ibex. In order to be able to compile code for it we need a toolchain (GCC or clang) with:

• Assembler support (essential, needed for Ibex DV)
• Support in binutils
• Compiler support beyond that will be needed at some point, but that's prio 2 for now.

We currently use a GCC toolchain, but this could be a motivating factor to switch to clang.

The current plan is to implement all subgroups of B instructions, so we probably don't need the ability to enable only subgroups (e.g. Zbb).

@lenary What's the current status of the B extension in LLVM and GCC?

Timeline: I'd expect the initial implementations to be committed in ~4 weeks from now, so we should have something ready in roughly that timeframe. This can of course be an out-of-tree patch we apply to a toolchain here in this repository.

CC @asb

[lenary]

The quick answer is no one has support for the bit manipulation extension yet. Not in clang trunk, and not in GCC/binutils.

As far as LLVM/Clang goes, the following sequence of patches exists, but has not been reviewed or applied:

1. ~TableGen Changes: https://reviews.llvm.org/D74338~ (Landed!)
2. ~Unratified Extension Support: https://reviews.llvm.org/D73891~ (Landed!)
3. ~Assembler Support: https://reviews.llvm.org/D65649~ (Landed!)
4. ~Codegen support: https://reviews.llvm.org/D67348~ (Landed, in per-subextension patches)
5. LLVM Intrinsics: https://reviews.llvm.org/D66479
6. ~Clang Support: https://reviews.llvm.org/D71553~ (Landed!)
7. Intrinsic Headers: https://reviews.llvm.org/D67661

1 is a target-independent change, which has almost been approved by everyone it affects. 2+ are all RISC-V specific, and we probably need only 1-3 (+ maybe 6) to land for assembler support.

In terms of other tool support:

• Linker: I think we would not have issues here, but I would not be able to guarantee it.
• Disassembler: We would need to move to llvm-objdump to disassemble bit manipulation instructions. I would need to check it was part of the LLVM toolchain being built.
• Debugger: gdb would be unable to disassemble bit manipulation instructions (but it would be able to debug through them, I think). We cannot move to LLDB because it does not yet support RISC-V.

Another solution is to look for binutils patches! There seem to be some available, here: https://github.com/riscv/riscv-bitmanip/tree/master/tools - this would allow us to entirely ignore the LLVM side of things for the moment, and wouldn't force us to switch to LLVM so quickly.

There are two potential courses of action:

1. Add the binutils patches to our toolchain builder script, and keep using gnu tools for the moment.
2. Switch to LLVM (if you need B support), apply patches (both to binutils and to LLVM, just in case), and add support to meson for choosing the LLVM or the GNU toolchain.

I think 1 is the more sensible course of action, which doesn't rush the switch to LLVM unnecessarily. Then we can apply the LLVM patches (or slowly land them) and switch to LLVM in our own time.

[imphil]

I agree (1) is the most actionable path forward, it's probably not too much effort and buys us a significant amount of time. Opened https://github.com/lowRISC/lowrisc-toolchains/issues/9 to get that done.

[imphil]

For LLVM: a branch with bitmanip patches is available at https://github.com/embecosm/llvm-project/tree/riscv-bitmanip

[lenary]

The patches are starting to land on LLVM master, which is fantastic!

[lenary]

I've started #14 to track adding a build of the combined toolchains that includes support for the B extension. There are a few issues to iron out, but we're most of the way there with the existing work.

[lenary]

We have preliminary B extension support for both GCC and Clang, but there are some outstanding parts, including the GCC functionality added by this PR: https://github.com/riscv/riscv-gcc/pull/166

The following toolchains have B support:

• 20200504-1
• 20200606-1

Any new toolchain builds will also have B support, if all goes to plan.

[lenary]

I'm going to start a new PR (done: #29) which sets -march to exactly what's in the 'Balanced` set described in this OT issue: https://github.com/lowRISC/opentitan/issues/2708

Reading the GCC patch, this should mean that GCC no longer emits B instructions during code generation, but as is still capable of assembling them. This required a terrible hack, but i think it should be stable enough.

[NazerkeT]

Hi there! Recently, I was building support for bitmanip for CVA6(Ariane) core and have finished it for subgroups Zbb, Zbp, Zbe, Zbs. I wanted to check it for performance, but as far as I have understood for a proper check I do need a good gcc /llvm support which I am wondering whether does exist or not. I have used flags -march, -mabi to enable z-parsing for subgroups, but anyways hit the fail. As far as I have understood from ibex PRs, it does not seem as straightforward as just using flags and have the following questions:

1. Could you please specify prerequisites for this run? Or is there any other hack involved?
2. Could you please, guide me on how can I run benchmarks (for example Dhrystone) with limited gcc support?
3. And how to actually enable gcc support correctly?

Thanks! Best regards,

[lenary]

@NazerkeT

To cover GCC first:

• We're using a patched version of GCC and Binutils - the patch is available in this repository.
• I wouldn't know how to guide you to run benchmarks with a specific compiler, surely you just point the makefiles at the right compiler instance, with the right flags.
• The patch we're using does not allow you to choose subsets of the B extension in GCC (but it does in the binutils assembler). My approach here has been not to enable B code generation at all in GCC, instead I worked out how to just enable assembling B instructions from the Balanced subset. This is complex and a bit fragile, but the approach is to provide the following arguments: -march=rv32imc -Wa,-march=rv32imczbb0p92_zbf0p92_zbs0p92_zbt0p92 -mno-riscv-attribute. You may want to provide a different prefix to the march string depending on whether your core implements M and C.

And for clang/LLVM:

• clang/LLVM Master now includes B Support for both assembling and code generation (though maybe not the version we use in this repo).
• Again, I cannot help you run a benchmark beyond saying point at the built compiler, and give the right flags.
• The Subset you want can be chosen for clang/llvm using -march=rv32imczbb0p92_zbf0p92_zbs0p92_zbt0p92 -menable-experimental-extensions (the second is required so you acknowledge the spec is unratified and the implementation may change).