[clang] [llvm] [RISCV][MC] Add MC support of Zibi experimental extension (PR #127463)

[Pengcheng Wang via llvm-commits]

wangpc-pp wrote:

> Thanks for addressing my comment. The LLVM change looks good to me.
> 
> Not related to LLVM but Zibi in general: Since this is the last available branch encoding, I am slightly concerned that we are basing the immediate allocation of this on static instruction count in SPEC2017. Could we gain more code density by having a slightly more complicated immediate? The PDF details the number of bits needed to convert a given percentage of branches, but I imagine certain values (e.g. multiples of 16?) are more common. I wonder if something slightly more complicated could match more immediates?
> 
> For example in the CHERI spec for [YBNDSWI we use one bit to indicate whether to shift the immediate by 4](https://riscv.github.io/riscv-cheri/#SCBNDSI). Would something like the current format work but with the immediate reduced to 4 bits and MSB being a "shift by 8/16/32"? flag? So you could represent `-1`, `-8`, `1-16`, `(1-16) << 8` instead of `-1` and `1-32`? I can't imagine numbers like 17 being super common. Anyway I will take this comment to the relevant RISC-V mailing list.

Thanks for your suggestion!

IIRC, similar questions have been raised when we were discussing the design. You can see this public Lark document: https://bytedance.sg.larkoffice.com/docx/PY09dRqkZoPQYrxPPStlMTrfgVc.

The conclusions are:

1. Negative values are not common and `-1` can cover almost 80% cases.
2. The immediate value has no obvious preference to power-of-2 values.

But YES, I agree that some values between `1-31` are not common and we don't know if the multiples of some values are more common. We haven't done such detailed investigation yet, we may make the immediates a table just like in Zfa's `fli` instruction, if there are evidences that show some benefits.

https://github.com/llvm/llvm-project/pull/127463