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

Pavel Iliin via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 6 04:37:42 PST 2023


ilinpv added a comment.

In D127812#4030881 <https://reviews.llvm.org/D127812#4030881>, @smeenai wrote:

> We're not actually using multi-versioning anywhere, but we're still paying the size cost for it as a result. Would we consider moving the newly added functions into their own file (or perhaps moving the outlined atomics functions into a different file), so that you can use outlined atomics without also paying the size cost of function multiversioning if you don't need it?

Function multiversioning expects compiler-rt has __aarch64_cpu_features, it will be broken if compiler-rt miss that ( clang/lib/Driver/ToolChains/Clang.cpp:7231 ). I believe function multiversioning will be used in Android as outline atomics already did.

> I also had a couple of general questions, since I think I'm missing something obvious:
>
> - How come we need both `init_cpu_features` and `init_cpu_features_resolver`? It seems like we're codegenning calls to the latter where needed, so I'm not sure what the former is adding on top.
> - From what I can see, we're codegenning calls to `init_cpu_features_resolver` without any arguments, but the actual definition of that function has two arguments. How does that work?

hwcaps are ABI specified arguments of ifunc resolver. The constructor init_cpu_features calls getauxval to initialize hwcaps and then pass them explicitly to init_cpu_features_resolver. If resolver called before constructor we get init_cpu_features_resolver hwcap and hwcap2 as arguments from dynamic loader.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127812



More information about the cfe-commits mailing list