Hi,
When building LLVM, is it always recommended to do it with the
latest official release, currently, it is 9.0.1? I ask because when I tried
it with a Debug build, it took an enormous amount of time on POWER8.
Were you trying to use a Debug build to build LLVM? Yes, that would be very slow.
If you mean you were using a release build of LLVM to build a Debug build of LLVM - yeah, that’s generally going to be recommended. Did this get slower/change significantly in performance? Many people have trouble with building Debug builds (no matter the host compiler) especially if they’re using bfd-ld, since it’s quite slow/uses a lot of memory. There are a few other issues to do with memory usage (do you have less than about a GB of RAM per CPU? Then you’ll probably hit swapping by default & have a bad time - there are ways around that)
David,
Yes, I was indeed trying to build LLVM with a Debug build. I’ll stop doing that from now on.
I am on JSC’s JURON machine which has 251 GB of memory on the login node, that’s more than sufficient
to do a build, I suppose, and the linker is LLD as LLVM has a CMake variable to select the linker.
David,
Yes, I was indeed trying to build LLVM with a Debug build. I’ll stop doing that from now on.
I mean, you can - it’s just going to be super slow & mostly not what you want, unless you’re trying to debug that building process. Usually you’d want to isolate one particular test case, maybe even reduce it, before running it with a debug build of LLVM which will be quite slow (because it’s not optimized at all).
I am on JSC’s JURON machine which has 251 GB of memory on the login node, that’s more than sufficient
to do a build, I suppose, and the linker is LLD as LLVM has a CMake variable to select the linker.
Yep, sounds like you’re just tripping over the fact that an unoptimized/debug build of LLVM is very slow. thumbs up
As I am facing the serious super slow down: https://bugs.llvm.org/show_bug.cgi?id=44407 , I’d like to
learn more about how it can be minimized. When debugging an app, there are times building it with a
Debug build LLVM can not be avoided, but a situation like 40 times time increase (40 minutes) is hard
to work with.
As I am facing the serious super slow down: https://bugs.llvm.org/show_bug.cgi?id=44407 , I’d like to
learn more about how it can be minimized. When debugging an app, there are times building it with a
Debug build LLVM can not be avoided, but a situation like 40 times time increase (40 minutes) is hard
to work with.
Not sure I follow - you shouldn’t need a debug build of clang to debug an application built with clang. You’d use a release build of clang to build your application with debug info (by passing -g).
At least, to obtain enough information from libomptarget while running my offloading app on GPU capable environment, I have to build it with an LLVM which was built in Debug mode.
I’m still confused by that - whether or not the LLVM you built has debug info in it shouldn’t at all change what goes into the binaries that LLVM produces (modulo a few bugs, but nothing that’d produce drastic performance swings). You mention in the bug that it’s specifically LIBOMPTARGET_ENABLE_DEBUG that is slowing down your compilation time? Not the use of a Debug build of LLVM? Have you tried a Release build of LLVM but with LIBOMPTARGET_ENABLE_DEBUG enabled?
I have just tried a Release build of LLVM but
with
LIBOMPTARGET_ENABLE_DEBUG enabled. The app build became super fast, but I can not obtain debugging information that I need at runtime.
I have just tried a Release build of LLVM but
with
LIBOMPTARGET_ENABLE_DEBUG enabled. The app build became super fast, but I can not obtain debugging information that I need at runtime.
I know nothing about OMP, so I might be completely off-base with all of this. But could you explain the specific steps you are taking (from building the compiler, running the compiler to build your program, executing the program, and what kind of debugging you are doing at runtime/how you are doing it) including any commands you run to do those actions, where possible?
The description for this flag seems to be: LIBOMPTARGET_ENABLE_DEBUG “Allow debug output with the environment variable LIBOMPTARGET_DEBUG=1”
Is this what you are looking for? Or are you looking into getting debug info (Dwarf) for the OpenMP runtime itself?
Yes, exactly.
Ah, OK, sounds lik LIBOMPTARGET_ENABLE_DEBUG doesn’t have anything to do with your problem, then. Bit of a red herring.
If the LLVM build doesn’t support /just/ building the runtime with debug info (if this is a normal/common scenario, to need to debug into the runtime library, perhaps it should - but I Have no idea if that’s a normal use case), then you can probably mix-and-match between two builds. Build the runtime with debug info and drop it into an installation of the compiler built in release mode?
I guess I like what you described, but that’s also beyond my toolchain build skills.
All,
Is it thought as acceptable for a user seeing 40 minutes of app build time if he is using
a “Debug” Clang? While, with a “Release” Clang, it just finishes within a minute.
I guess I like what you described, but that’s also beyond my toolchain build skills.
I’d suggest looking at how the OMP program is linked - probably some linker verbose flags would tell you exactly which library it is that is being linked into your binary (maybe inspecting the debug info would lead you to this too) & take the library from a debug build and copy it over into the release installation.
All,
Is it thought as acceptable for a user seeing 40 minutes of app build time if he is using
a “Debug” Clang? While, with a “Release” Clang, it just finishes within a minute.
Yep, an unoptimized Clang will be really slow, that’s not surprising/a bug, as such - it’s necessarily unoptimized, which is slow. It’s possible that there are opportunities for performance improvement there (without hurting code quality, making the changes hard to easily regress, etc). You could potentially do RelWithDebInfo - no idea if that’d make the OMP library hard to debug or not (optimized code/debug info is not as easy to work with).