[Llvm-bgq-discuss] New bgclang nighty builds (and other updates)

Hal Finkel hfinkel at anl.gov
Thu Mar 19 18:15:13 CDT 2015


Hello everyone,

First, let me apologize to everyone, this is a few months late... but, hopefully, this will never be a problem again...

I now have a system setup which automatically pulls in upstream changes and tries to merge those with the bgclang-specific patches, and then builds the resulting suite of bgclang RPMs. When this succeeds, the RPMs should be posted automatically to:

  http://www.mcs.anl.gov/~hfinkel/bgclang/
  (note that installing a build from here now also requires both the 'stage1' and 'stage2' RPMs as well)

The first such nightly build, r232720-20150319, has been posted to that page.

And, for the curious, the local repositories used for version control are now mirrored to github:

  https://github.com/hfinkel/clang-bgq
  https://github.com/hfinkel/llvm-bgq
  https://github.com/hfinkel/bgclang-aux
  https://github.com/hfinkel/compiler-rt-bgq
  https://github.com/hfinkel/libcxx-bgq
  https://github.com/hfinkel/openmp-bgq
  https://github.com/hfinkel/sleef-bgq

Compared to the latest "released" version (r220548-20141024), the most-recent nightly build does show some performance regressions, and there are a few things I've not even tested yet (LTO, ASan, etc.), but it also contains a number of bug fixes and improvements, so feel free to test on your applications.

One particular noteworthy improvement is that our OpenMP runtime library now has affinity support enabled. This means that all of the OpenMP 4 affinity features should work, and also that the default thread<->core bindings are now sensible.

The bgclang wrapper script no longer disables 'fast-isel' instruction selection at -O0, so your debug builds should now be faster too. Also, the automated vectorization of math functions using our SLEEF library adaptation is controlled using the new -fveclib flag (so the wrapper script contains -fveclib=SLEEF, and you can add -fveclib=none to turn it off if desired for whatever reason).

Also, the core QPX support has been contributed upstream (although not yet the Clang-level intrinsics support); so if you're using LLVM as a library, and want to just build from upstream sources instead of depending on the bgclang builds, that is now possible.

Thanks again everyone, and please let me know if you experience any difficulties,
Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-bgq-discuss mailing list