[compiler-rt][AArch64] Rewrite SME routines to all use __aarch64_cpu_features.

[sdesmalen-arm]

When #92921 added the __arm_get_current_vg functionality, it used the FMV feature bits mechanism rather than the mechanism that was previously added for SME which called getauxval on Linux platforms or __aarch64_sme_accessible required for baremetal libraries. It is better to always use __aarch64_cpu_features.

For baremetal we still need to rely on __arm_sme_accessible to initialise the struct.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[DanielKristofKiss]

Maybe the compiler-rt/lib/builtins/cpu_model/aarch64/fmv/baremetal_sme.inc could drop the SME from the filename and the macro name as it could do more later.

LGTM otherwise.

[jroelofs]

I'm not sure we want this on Darwin and maybe Fuchsia platforms, since it would require calling __init_cpu_features_resolver to initialize __aarch64_cpu_features. On some platforms that happens automatically via an __attribute__((constructor)) function, but Darwin and Fuchsia don't, and instead rely on an FMV resolver triggering it.

cc @aemerson

[aemerson]

I'm not sure we want this on Darwin and maybe Fuchsia platforms, since it would require calling __init_cpu_features_resolver to initialize __aarch64_cpu_features. On some platforms that happens automatically via an __attribute__((constructor)) function, but Darwin and Fuchsia don't, and instead rely on an FMV resolver triggering it.

cc @aemerson

There's no immediate concern for Darwin because we have our own parallel implementations of the SME runtime routines.

[sdesmalen-arm]

On some platforms that happens automatically via an __attribute__((constructor)) function, but Darwin and Fuchsia don't, and instead rely on an FMV resolver triggering it.

Is there a technical reason for that or is this just an implementation choice?

[jroelofs]

On some platforms that happens automatically via an __attribute__((constructor)) function, but Darwin and Fuchsia don't, and instead rely on an FMV resolver triggering it.

Is there a technical reason for that or is this just an implementation choice?

All the existing uses of it on Darwin platforms are lazy, and thus you don't pay for what you don't use. And in general, we try really hard to avoid global ctors/dtors as they tend to dirty pages, increase launch times, etc.

[jroelofs]

There's no immediate concern for Darwin because we have our own parallel implementations of the SME runtime routines.

Well, we have a downstream one. I think we should avoid making the upstream one incorrect and/or slower than it needs to be.