HELP WANTED:Clang toolchain compile with -fopenmp cause so size increase nearly 400K

cocodark commented 6 years ago

As descripted in title, the latest ndk r17 set clang as the default toolchain, the -fopenmp command cause shared library size increase as much as nearly 400Kb, but gcc in the previous version, the -fopenmp only cause increasing about 30Kb, what's the difference between gcc & clang?

cocodark commented 6 years ago

@pirama-arumuga-nainar Any suggestions?

pirama-arumuga-nainar commented 6 years ago

I am able to reproduce this with a simple case.

int g[1024];

int main() {
  int i;
#pragma omp parallel
  for (i = 0; i < 1024; i ++)
    g[i] = i*i;
  return 0;
}

With OpenMP, executable from GCC is 40K, while the one from Clang is 380K. This seemed to have been worse with r16, where the Clang generated binary was ~800K.

There are far too many functions in the text section and symbol table with Clang than with GCC. I'll see why this is and if we can trim this down. If it helps in the meantime, adding '-Wl,--exclude-libs,libomp.a' reduces the binary to 350K. The savings are mostly from a smaller symbol table. The text section is still big.

cocodark commented 6 years ago

@pirama-arumuga-nainar As Gcc will be removed in r18, this bug cause a lot trouble to us

pirama-arumuga-nainar commented 6 years ago

Using -ffunction-sections when building the libomp runtime and passing -Wl,--gc-sections while linking (which, according to @DanAlbert, is passed by ndk-build and CMake by default) helps shave a further 100k from my test. With this change, the clang-build with openmp is ~250K, which is still higher than the 40K from gcc.

This is all I can think of from a black box perspective. I'll kick off an email to openmp-dev asking for their opinion.

I've attached libomp.a.zip for arm64 built with -ffunction-sections for experimentation. Just drop it into your NDK installation.

pirama-arumuga-nainar commented 6 years ago

https://android-review.googlesource.com/c/toolchain/llvm_android/+/719087 passes ffunction-sections when building the runtimes. This should be a part of r19 or whenever the NDK clang gets updated past the one in r18.

cocodark commented 6 years ago

@pirama-arumuga-nainar Is there any progress？

pirama-arumuga-nainar commented 6 years ago

@cocodark did this help?

I've attached libomp.a.zip for arm64 built with -ffunction-sections for experimentation. Just drop it into your NDK installation.

I have to ask upstream OpenMP developers about this - and for that I need to recreate my experiment with a newer gcc. I'll do that this week.

cocodark commented 6 years ago

@pirama-arumuga-nainar After replace the libomp.a, clang still cause increase ~250K ,this is still inexplicable, which force me to revert to R14 with GCC, so ,I hope it will be resolved before NDK R18 released.

DanAlbert commented 6 years ago

I hope it will be resolved before NDK R18 released.

If we find out that we're just building something wrong then that's possible, but if it's something that will require changes upstream then unfortunately that won't happen. It takes quite a bit of time to get changes made, merged to LLVM, pulled back to Android, tested, and then finally released.

Has anyone looked to see if the same size issues are present with prior NDKs? We've had openmp support for Clang for over a year but this bug was only opened about two weeks ago.

DanAlbert commented 5 years ago

As far as I know this has not been resolved upstream, so moving to r20.

cocodark commented 5 years ago

@DanAlbert Thank you

DanAlbert commented 5 years ago

Still no upstream progress.