This adds IR level intrinsics for the proposed Bit Manipulation extension.
Details on the extension can be found here: https://raw.githubusercontent.com/riscv/riscv-bitmanip/master/bitmanip-0.90.pdf
These intrinsics all use llvm_anyint_ty. The arguments can currently only be either 32 bit or 64 bit and nothing else. Is there better way to achieve this without using llvm_anyint_ty?
I haven't added intrinsics for every new instruction. Either because they are too simple (andn, orn, xnor, min and max) or because there is already an IR intrinsic that has the same function (clz, ctz, pcnt, ror, rol, fsl and fsr).
I considered using a multiclass for these GREVI patterns and a few other similar patterns in this file. Would this be a better approach?
I agree, and I raised that possibility ~3 years ago (and it was debated well before that time too):
If there's new evidence to suggest we should have those intrinsics, please send a note to llvm-dev. Then, it can be seen by more people. It's not clear to me how this patch review would be changed.
I note that GCC support for RISC-V bit manipulation extension defines a set of builtins (not yet upstream, available at https://github.com/riscv/riscv-bitmanip/blob/master/cproofs/rvintrin.h), and that this set of builtins has been agreed with Clifford Wolf, chair of the Bit Manipulation Task Group and author of the instruction set extension definition document.
Clang/LLVM should support this set as a minimum in order to ensure that code that works on GCC works out of the box on Clang/LLVM.
A frontend(clang) intrinsic, LLVM IR instruction/intrinsic, backend RISCVISD node and finally RISCV instruction
In order to have a frontend(clang) intrinsic/builtin, you don't need anything from the rest of the compiler,
You don't need to have any specific LLVM IR instruction/intrinsic for every ISA extension,
You raise a good point.
For future reference: Here is a link to similar discussions on the mailing list: https://lists.llvm.org/pipermail/llvm-dev/2019-August/134791.html