Here’s the situation. I’m on macOS, where Apple Clang is already installed, but I also need OpenMP to build PyTorch. So I’m trying to install LLVM OpenMP using Spack. However, there seems to be a bug, and I’m not sure whether it’s a bug in PyTorch or in LLVM OpenMP. So now I’m trying to run make check during the LLVM OpenMP install, but the build complains that it can’t find “not”. This seems to be an LLVM utility. Is it possible to install this utility without installing the entire LLVM monorepo? Bonus points if anyone can help solve the aforementioned OpenMP bug.
Installing LLVM from scratch should not be the problematic part but I understand.
Could you share a script that reproduces your steps, I’ll try to take a look at it.
Yes, installing LLVM from scratch is slow but it should work, although I had some issues on aarch64 in the past.
Steps to reproduce the PyTorch/OpenMP bug can be found here: torch.einsum results in segfault · Issue #80805 · pytorch/pytorch · GitHub
Note that you must be on macOS arm64 (Apple M1/M2) to reproduce the bug.
That bug might have been fixed in LLVM 16.
Thanks, I’ll try that. I tried adding LLVM OpenMP 16.0.0, but the install process seems much more complicated now that the required CMake files are in a separate tarball. Shouldn’t be impossible to do in Spack, just need to figure out the right way to package it.
Just tried with LLVM OpenMP 16.0.0 but unfortunately the bug still exists.
Do we already have GitHub issue in LLVM project for that? If not, could you please open one such that we can track it.
I haven’t opened an issue yet. A quick search finds many OpenMP + segfault issues, but I don’t know enough about OpenMP to know if any of them are the same issue: Issues · llvm/llvm-project · GitHub
If you want I’m happy to open a new issue on GitHub.
It didn’t reproduce on my M2 with apple clang 14.0.0 and openblas without Fortran. This could mean that you have a (bad) workaround, and that the issue is probably located there.
Opened a GitHub issue to track this: OpenMP segfault on macOS arm64 · Issue #61682 · llvm/llvm-project · GitHub. Let’s continue the discussion there.
Still curious if there’s a way to install this “not” utility without installing the entire LLVM monorepo though…
The not utility depends directly on LLVM utilities. So building it requires LLVM. Someone could potentially package it in a standalone format with statically linked LLVM libraries. But it’s unlikely there would be much utility in that. You could replicate its functionality similarly if you were so inclined. All it does is execute the program given on the command line and returns the opposite of what the program returned.