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