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

[Philip Reames via llvm-commits]

preames wrote:

> One of the points of having an abstraction, whether like this or otherwise, is that you don't need to have per-OS code in the compiler to handle multi-versioning. This format is simple enough that it's not tied to one OS, and the extensions specified by a body other than a specific OS, unlike hwprobe which is defined by Linux and has an interface tied to it (e.g. the use of its notion of CPU sets). This is something FreeBSD can realistically implement.

@jrtc27 Is there an interface provided by e.g. FreeBSD that we should be looking at here?  If not, this seems like somewhat of a moot argument. 

As a second point, asking from ignorance here as I honestly don't know, don't we generally know the target OS from the triple?  Generating code which has to work on any OS versus some specific OS seems like a generally harder problem.  The dependent patches already have e.g.:
```
  if (getContext().getTargetInfo().getTriple().getOS() !=
      llvm::Triple::OSType::Linux) {
    CGM.getDiags().Report(diag::err_os_unsupport_riscv_target_clones);
    return;
  }
```

Is your argument that while we *can* generate OS specific code, we should prefer not to?  If so, that seems like a reasonable code quality point, but I don't see how it's in anyway blocking.  We can ship a version of the compiler with the OS specific enable, and then generalize once we have a second example, and sink common APIs into compiler runtimes if useful.   It also seems like a concern which deserves to be balanced with e.g. the timeline to expose a new extension as opposed to a hard and fast rule.  



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