compiler-rt: Provide __cpu_indicator_init, __cpu_model and __cpu_features2

[lacc97]

Fixes #18074, original PR was #18193.

This PR adds support for X86/X86_64 CPU model detection and function multiversioning in C/C++ via the target and target_clones attributes (compatible with LLVM's, which in turn is compatible with libgcc's). It adds __cpu_indicator_init, __cpu_model and __cpu_features2 symbols to compiler-rt for x86/x86_64 which reuse the CPU detection logic under std/zig/system/x86.zig and transform the detected features into the values expected by LLVM-generated code. These values are kept in sync with LLVM using a new tool (tools/update_x86_cpu_model_enums.zig) which parses llvm/include/llvm/TargetParser/X86TargetParser.def in LLVM to generate the corresponding Zig enums.

This PR also adds a standalone test that the symbols are emitted when the target attribute is used in C.

While this functionality could in principle contribute to solving issue #4591 (edit: wrong issue, its #1018), I think it would be best to use a Zig-specific solution for richer CPU detection capabilities, leveraging std.Target.* instead of relying only on the feature set supported by LLVM/libgcc. The changes in this PR would therefore only be useful for C/C++ compatibility with Clang and gcc.

[daurnimator]

I could have sworn there was an issue about function multiversioning/selection based on runtime-detected CPU in Zig itself but I can't find it now

#1018 ?

[lacc97]

I could have sworn there was an issue about function multiversioning/selection based on runtime-detected CPU in Zig itself but I can't find it now

#1018 ?

Yep that was it. Thanks.

[theseyan]

Missing support for these symbols is a blocker for compiling libmdbx (a fork of LMDB) with Zig:

error: ld.lld: undefined symbol: __cpu_indicator_init
    note: referenced by gc-get.c:584 (src/gc-get.c:584)
    note:               mdbx-static.o:(scan4seq_resolver) in archive [...]/libmdbx.a
error: ld.lld: undefined symbol: __cpu_model
    note: referenced by gc-get.c:587 (src/gc-get.c:587)
    note:               mdbx-static.o:(scan4seq_resolver) in archive [...]/libmdbx.a

I really appreciate this PR and hope it gets merged soon. 🫡

[slyshykO]

As a temporary solution, you can use cpu_model, which provides __cpu_indicator_init and __cpu_model symbols.

[lacc97]

Rebased to latest master.

[lacc97]

Rebased again . I'm not entirely happy with getAmdTypeAndSubtype() and getIntelTypeAndSubtype() as it seems to duplicate similar logic as in lib/std/zig/system/x86.zig. It's not clear to me how to resolve this without bringing in the generated enum types inside the standard library, which don't really fit there.

[alexrp]

It's not clear to me how to resolve this without bringing in the generated enum types inside the standard library, which don't really fit there.

Is it actually problematic if the standard library @imports a file from compiler-rt or vice versa? If it just contains data, as seems to be the case, that seems to me like it'd be harmless?