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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
