-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support building with flang on windows #4768
Comments
right, flang on Windows appears to be lagging behind the Linux/Unix version. If there is no omp_lib module provided by LLVM, I suggest you open an issue with them (unless already known/documented). This may also be the reason why you needed to set a bunch of cmake variables manually |
but ISTR broken OpenMP support in LLVM on Windows is a known problem, and your "flang 19" is an unstable snapshot |
Do you have a link?
Yes, 19.1.0rc1 is only expected in about a month. The problem was that all flang 18 builds were broken for SciPy, and I wanted to test/ensure that things work with flang 19 (early enough for potentially necessary fixes to land), hence why I built from main, as noted in the OP. |
somewhere in the discussion in #3973 I think, but it could be that it was broken once, worked for a while and is now broken again. |
It seems upstream intends to support it. I'm trying to rebuild as necessary to test that hypothesis. Meanwhile, I've had one passing run without OpenMP, however, the logs got spammed so badly with warnings (~500MB), that I cannot really check them. After running again with warnings ignored, I get:
The runtime especially of complex-valued procedures is off the charts. That's also the part that depends on LLVM's compiler-rt (instead of MSVC's runtime); not sure if that plays a role somehow. An excerpt:
|
FWIW, the time to run
So flang takes about 50% more time. |
on a rerun of the flang-built openblas (without openmp), I now get:
My suspicion is that the CI agents switching between different CPU types randomly is the cause for the pass or fail. If necessary, I can try to validate that hypothesis. |
maybe alternating between avx512 and non-avx512 , common problem with azure-ci and ISTR mmuetzel had noted problems with win-llvm and avx512 previously |
omp mod problem could also be missing include path to modules in llvm install path. will try to look at your logs later if able |
It fails with the following instructions found for the CPU of the CI agent (according to numpy):
I managed to fix the
|
The lpthreads argument error is probably bogus. Do you see |
Passing configuration (non-openmp):
So indeed some AVX512 issue seems likely |
Yeah, I'm even passing that explicitly in |
seen some google hits suggesting that it is simply fallout from one of cmake's standard configuration check scripts and can be ignored. |
Looking closer, I'm almost certain this is a question of the wrong library path being picked:
Both of these are pointing to the build environment, not the host where openmp is actually present. Perhaps the path is constructed relative to clang/flang? |
Two good news, two bad news Good news
|
OpenBLAS already added flang support, but I don't think this is being tested on windows? While reviving the old effort to build conda-forge's
openblas
with flang, I originally ran into some parsing issue with flang 18.Luckily, with a flang 19 built from main (already built for debugging something else, so I thought I'd try), it seems that particular issue is gone. 🥳
However, I first encountered some CMake detection issues:
After iteratively figuring out (also re-encountering #3069 again along the way) that I needed to add (something like)
I then ran into what looks like a regular compilation error:
The text was updated successfully, but these errors were encountered: