[PATCH] D127812: [AArch64] FMV support and necessary target features dependencies.

Shoaib Meenai via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 6 10:11:25 PST 2023


smeenai added a comment.

In D127812#4031849 <https://reviews.llvm.org/D127812#4031849>, @ilinpv wrote:

> In D127812#4031313 <https://reviews.llvm.org/D127812#4031313>, @smeenai wrote:
>
>> We can use `-mno-fmv` to avoid that dependency, right? We're interested in using that for our own code (where we don't make use of function multi-versioning), and want to prevent the compiler-rt support from being pulled in from the archive unnecessarily. It'd still be available for users who needed it.
>
> Right, you will need to explicitly provide '-mno-fmv` then. Currently __aarch64_cpu_features cpu_model.c stuff located in bultins (`libclang_rt.builtins-aarch64.a`). Did I understand you correctly that your apps linked agains libclang_rt.builtins-aarch64.a and if we move function multiversioning part to new library, lets say `libclang_rt.cpu_features-aarch64.a`, that will resolve your concern ? As a sidenote, builtins/cpu_model.c contains X86 CPU features used in function multiversioning on that target as well.

It doesn't need to be in a separate library. It just needs to be in a different source file than the outlined atomics, so that it only gets included in the link if it's explicitly referenced and not just because outlined atomics are used.

You're right that it conceptually makes sense for this to be in `cpu_model.c` though. An alternative would be providing an option for compiler-rt to be built without the multiversioning support, e.g. if it's built with `-mno-fmv` itself. Does that seem reasonable?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127812/new/

https://reviews.llvm.org/D127812



More information about the llvm-commits mailing list