Clang not compiled with OpenMP support

[cmaster11]

It is impossible to use OpenMP with Clang from scratch, whil GCC still has it.

With the deprecation of GCC, Clang should be built with its support.

[DanAlbert]

@stephenhines any idea what we need to get openmp in clang?

[stephenhines]

I think it requires us pulling down another external project to build (http://openmp.llvm.org/). This is something of a feature request, because the prior Clang toolchain shipped in the NDK was from a different forked set of sources (that likely included this library).

[DanAlbert]

Okay, tentatively triaged for r12, but that might slip a ways unless I'm seriously underestimating the demand for openmp on mobile devices.

[stephenhines]

I filed an internal bug for this as well: Bug, so that we can keep track of what is needed (creation of new repos, etc., that can't be easily handled here on the github tracker).

[cmaster11]

Technically, clang just needs to be compiled with openmp support, if ndk's clang
is a direct port of the original project, as stated in its homepage
http://openmp.llvm.org/

Also, release notes of r11 state that clang3.8 got introduced, but only 3.6
looks available. When upgrading to post 3.7, openmp support should be
straightforward as it should be integral part of clang itself:
http://openmp.org/wp/2015/08/clang-37-will-have-full-openmp-31-support/

Just entirely upgrading clang to 3.8 should fix the issue.

[DanAlbert]

Also, release notes of r11 state that clang3.8 got introduced, but only 3.6
looks available.

There are still a number of files that have "3.6" in the name, but that's just cleanup I didn't finish (because it's afaik not in anywhere user visible). It is in fact a 3.8svn release.

$ android-ndk-r11/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
clang version 3.8.243773
Target: x86_64-unknown-linux
Thread model: posix

[cmaster11]

@DanAlbert

underestimating the demand for openmp on mobile devices

OpenMP support is a huge benefit for every heavy computing task. We use it daily together with RenderScript for computer vision problems and really gives a boost in performances. The lack of openmp in clang is not a problem, but as there is the suggestion to switch to it instead of gcc, to have it support all gcc extensions should be a must :)

Also, as it is the 3.8 release, then it just needs to be compiled with openmp support and will work directly out of the box.

In any case, great work you're doing there ;)

[stephenhines]

It is actually clang 3.8, but not the official release version, since we track TOT LLVM, and not their release branches. Since I am not all that familiar with OpenMP, perhaps you can tell me how this is failing to compile/link. What are the exact error messages/symptoms you are seeing, since you seem to indicate that it should be included as part of Clang/LLVM. I would like to be able to verify that this works before shipping another version that fails.

[cmaster11]

@stephenhines , I'll give it a try and report about how to add it's support :)

[il-alexk]

Another vote for the openMP being a must for clang. Hope you will be able to add it to the r14 as planned.

See this link for a potential issue and a workaround related to a thread storage issue.
http://www.softwarecoven.com/parallel-computing-with-openmp-in-android/

[DanAlbert]

Quick update here:

@pirama-arumuga-nainar got this mostly up and running (thanks!), but there are actually some issues with the way the Clang driver tries to use openmp. Unlike most Clang runtime libraries, OpenMP actually can't be installed into a multilib toolchain (the libraries ought to be libclang_rt.openmp-$ARCH-android, but are just looking for libomp.

@pirama-arumuga-nainar is working on upstreaming a fix for this, but unfortunately it does mean this isn't likely to be fixed in r14.

[rcketscientist]

Hate +1s and see you guys are working on this, but didn't see it in r14 so just wanted to say it's a blocker for me as well. Finally worked through the kinks in switching to clang for my app, but I'll be stuck on gcc until this is in place.

[DanAlbert]

We're working with the openmp devs to get this working for cross compiling. Discussion here: http://lists.llvm.org/pipermail/openmp-dev/2016-December/001612.html

Lots of the industry slows down over the holidays, so I don't expect we'll see anything move forward until the new year. Assuming they agree to our plans, we should have a patch in with plenty of time for the r15 release.

[DanAlbert]

@pirama-arumuga-nainar: has there been any progress on this upstream?