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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
