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