[compiler-rt] [compiler-rt][RISCV] Implement __init_riscv_feature_bits (PR #85790)

[Philip Reames via llvm-commits]

preames wrote:

Following up to conversation from the RISCV sync up call yesterday.

LGTM to the approach.  I'm deferring to Kito on the implementation details of compiler-rt.  This LGTM is subject to the requirement that this patch is reverted from the release branch if for any reason the dependent compiler default ifunc resolver change doesn't make it into the release.

As broader context (as much for my future self as anything else).  We have three major options on the default resolver approach.
* We could just use hwcaps.  This is pretty universally rejected as the bits are ambiguous in several known cases, and only cover a handful of extensions.
* We could use the libc entry point to hwprobe provided to the resolver in the second argument register.  This is only available in glibc 2.40 and later, before that a nullptr is passed (args are nullptr terminated.)  2.40 is unreleased, and we don't want to dependent on an unpublished ABI.  As such, this option would require we delay this feature until 20.x.
* This approach.  The downsides of this approach are that a) most users use libgcc not compiler-rt, and b) we have an extra dependency layer which may slow pickup of future extensions.  The benefit is that a clang toolchain using compiler-rt picks up this feature at least 6 months sooner.  There's also some discussion of backporting the corresponding libgcc change.  

The later two both have pros and cons.  I personally would mildly prefer the second option, but am deferring to the folks who've worked on this as the third choice (this one) is at least reasonable.  Worth noting is that even if we land this, if we later decide the versioning upgrade thing is a major problem, there's nothing preventing a future compiler version from switching to the glibc entry if available.  





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