MSVC OpenMP: switch to the /openmp:llvm runtime - #184
Merged
Conversation
The classic and experimental MSVC OpenMP modes implement OpenMP 2.0, which limits parallel-for indices to signed 32-bit integers. RandBLAS consumers -- RandLAPACK in particular -- parallelize loops with int64_t indices and use the collapse clause, both of which only compile under the /openmp:llvm runtime. That runtime also supports the omp simd directive the sparse kernels use, so nothing here regresses. Also fixes an un-overridability bug: the post-find_package re-stamp of OpenMP::OpenMP_CXX hardcoded the mode, so passing -DOpenMP_CXX_FLAGS= at configure time silently lost. The requested flags are now captured before the find and re-applied afterward.
Contributor
Author
|
@rileyjmurray Need this approved to finish my RandLAPACK PR |
CI answered the open question from the /openmp:llvm switch: MSVC's llvm mode rejects the simd directive outright (error C7660), while the experimental mode accepted it but ignored the reduction clause without vectorizing the loop -- the directive has never bought MSVC anything. Compile it only for compilers whose OpenMP actually implements it, and keep /openmp:llvm as the MSVC mode (64-bit loop indices and collapse, which downstream consumers need).
Contributor
Author
|
@rileyjmurray All checks pass now. |
rileyjmurray
approved these changes
Aug 6, 2026
mmelnich
added a commit
that referenced
this pull request
Aug 13, 2026
…ackaging Three additions and one correction. A quick-start section at the top, because the installers are now the shortest path to a working RandBLAS and the guide opened by describing the manual one. It states the toolchain contract plainly -- you bring a C++20 compiler, CMake 3.21 and Git, the script supplies everything above that -- and covers sharing a dependency tree with RandLAPACK through RANDNLA_PROJECT_DIR, and why examples are opt-in. Appendix B, a tested-configuration table. Every row is a CI lane, so it says what is actually exercised rather than what we believe should work. It also explains the integer-width policy and, in particular, why OpenBLAS is the awkward case: BLAS++ probes int32 before int64 and blas_int only filters library names, so for MKL the choice is real and verifiable while for OpenBLAS an LP64 build passes the int32 probe and is accepted. Anyone with an ILP64 OpenBLAS has to point at it explicitly, and now the documentation says so. Appendix B also carries the packaging contract for conda-forge and Spack: which dependencies are actually required, that nothing is downloaded during configure, that LP64 is the default and therefore agrees with conda-forge's libblas metapackage, that RandBLAS never selects a BLAS itself, and that the installed package relocates correctly. Correction: the guide said RandBLAS selects /openmp:experimental under MSVC. It selects /openmp:llvm, and has since #184.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the Windows portability work in #179.
What #179 did: made RandBLAS build natively with MSVC, including the CMake logic that selects an MSVC OpenMP mode. It chose
/openmp:experimental, the minimum needed for RandBLAS itself: plain/openmpcannot compile theomp simddirective in the sparse kernels.What this PR changes: the selected mode becomes
/openmp:llvm. The experimental mode is still OpenMP 2.0 underneath, which only allows signed 32-bit loop indices and has nocollapseclause. RandLAPACK parallelizes loops withint64_tindices and usescollapse(2), so with the experimental mode pinned here, RandLAPACK's native Windows builds (BallisticLA/RandLAPACK#154) have to disable OpenMP entirely. The LLVM mode supports 64-bit indices,collapse, and everything the experimental mode provided, includingomp simd— so RandBLAS keeps compiling as before and downstream consumers stop being blocked.Also fixed along the way: the re-stamp of
OpenMP::OpenMP_CXXafterfind_packagehardcoded the mode string, so a user passing-DOpenMP_CXX_FLAGS=...at configure time was silently overridden. The requested flags are now captured before the find and re-applied afterward, in both the build tree (CMake/OpenMP.cmake) and the installed package config (RandBLASConfig.cmake.in).Validation: the Windows CI matrix from #179 (openmp-release leg, 459 tests) is the gate — it exercises the sparse kernels'
omp simdunder the new mode. Serial and ASan legs are unaffected.Downstream plan: once this merges, RandLAPACK bumps its submodule pin and adds an OpenMP leg to its own Windows CI.