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

[Shoaib Meenai via Phabricator via llvm-commits]

smeenai added subscribers: yozhu, lanza, smeenai.
smeenai added a comment.

I'm investigating a size increase we observed after this change for Meta's Android apps. This increases the size of compiler-rt by 1.6 KB, which is small by itself, but then compiler-rt is statically linked into each SO, and some of our apps have hundreds of SOs, so the increase adds up to a sizeable total. (We would ideally have far fewer SOs, but that's a pretty involved change.)

`-mno-fmv` doesn't help. What I've found is that `cpu_model.c` is getting pulled in from the compiler-rt archive into our SOs because of references to outlined atomics (`__aarch64_have_lse_atomics`), and then it has the static constructor `init_cpu_features`, which pulls in `init_cpu_features_resolver`. 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?

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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127812