[clang] [llvm] [X86] Extend kCFI with a 3-bit arity indicator (PR #121070)

[Scott Constable via llvm-commits]

scottconstable wrote:

> > maurer: I think their point is that even if you are not changing the hash scheme, you are proposing breaking compatibility of the identifier with existing code. Since we don't want to do this many times, if we are breaking compatibility with existing code, they would like to batch it with another breaking update so that it doesn't need to be done again.
> > (This isn't me reviewing this PR, just trying to clear up some confusion.)
> 
> This:) Thanks for the explanation.
> 
> After my pending lld/MachO change, kcfi will be the only user of the legacy `xxHash64`. I want to remove `xxHash64` from llvm-project.

Going back to @maurer 's comment about compatibility, I do not believe that this PR would break any compatibility with other compilers, or with other compiler versions. If a kernel is built with some of its functions having the 3-bit arity extension and the rest of its functions not having the 3-bit arity extension (e.g., because the user's clang compiler has the extension, and their rust compiler does not), then the kernel will behave the same as it would if all functions or no functions have the 3-bit arity extension. If the kernel is hot-patched with the register hardening scheme in https://lkml.org/lkml/2024/9/27/982, then only the functions that have the 3-bit arity extension will benefit from the register hardening scheme.

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