-
Notifications
You must be signed in to change notification settings - Fork 15
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
Add building and testing of PGO+LTO LLVM and Julia #345
base: main
Are you sure you want to change the base?
Conversation
I don't think I have permissions to fix |
Build currently failing as the bump to patchelf JuliaLang/julia#53845 introduced a check that the compiler supports C++ 17. Not sure why that check is failing on CI as it does seem to be using clang 16. We run The line that runs the check is https://github.com/NixOS/patchelf/blob/99c24238981b7b1084313aca8f5c493bb46f302c/configure.ac#L35 and the macro defined in https://github.com/NixOS/patchelf/blob/master/m4/ax_cxx_compile_stdcxx.m4. The only obvious difference I see is the |
Maybe |
Ok so the actual error is
JuliaLang/julia#45641 (comment) mentions something about libstdc++ detection, so maybe something to do with that. |
Is that a partial gcc 10 install? No g++10 / libstdc++-10-dev? You can force clang to use gcc 9 if necessary with Notice that |
I'm quite out of my depth here but I'm not sure gcc is installed in
|
It does seem to find the correct gcc version now. Yes, it does seem to get through patchelf's configure phase but now fails at making it
|
The build environment likely contains just the C compiler part of GCC 10, and clang has poor detection & heuristics for the GCC install dir. If multiple are in the same prefix it picks the newest, and it will do so also when there are missing components like C++ stdlib header files. The Use |
On the previous commit I saw
So I presume the specified path was wrong. |
Thanks, it seems to be working much better now. I just need to figure out why there's a hash mismatch, I had the same locally but I just refreshed it. |
f2ffa42
to
5ebf7b5
Compare
This looks good to me, testing was 15% faster. If we want |
Somewhat hacky way to fix JuliaCI#314 and to get JuliaCI#345 working again.
94f7c00
to
a0b0a3b
Compare
I discussed this with @Zentrik a few days ago: I believe it'd be great to actually test the PGO+LTO pipeline, but I'm a bit concerned with the extra long job this introduces. One option could be to move the job as a scheduled one, with the counter effect few eyes will look at it and the risk this will bitrot at some point. What do people think? |
In terms of speeding up the build job we could build the instrumented LLVM on yggy. Further, we could only profile periodically, e.g. every LLVM upgrade, allowing us to skip the slow profiling step and to distribute the optimised LLVM from yggy. |
I ended up just using the profile from Julia being built for PGO, locally it seems to work fine. If anyone has better ideas for what to profile, please do say.
I don't think we need to run the full test suite but it seems good to run at least some stuff to make sure nothing got messed up. The testing seems to finish a fair bit quicker than the gnuassertrr tests and not that far behind the other test pipelines, so this shouldn't slow down CI much.