-
-
Notifications
You must be signed in to change notification settings - Fork 5.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
Bump LLVM to v17 #53070
Bump LLVM to v17 #53070
Conversation
We've just upgrade to LLVM 16, 1 or 2 weeks ago (#51720). Welcome to the Julia community. |
I just found out https://github.com/llvm/llvm-project/blob/23b233c8adad5b81e185e50d04356fab64c2f870/llvm/docs/OpaquePointers.rst#migration-instructions The following commits might not be completely correct: If we revise these commits and fix the remaining deprecation warnings (which I believe are all related to the Opaque pointers transition), then builds for all platform should succeed. |
66c13ac seems fine, it seems they've changed the order these things need to happen, you can maybe even move the |
diff --git a/src/intrinsics.cpp b/src/intrinsics.cpp
index c784727c4f5..ff3c55bc072 100644
--- a/src/intrinsics.cpp
+++ b/src/intrinsics.cpp
@@ -4,6 +4,10 @@ namespace JL_I {
#include "intrinsics.h"
}
+#include <array>
+#include <bitset>
+#include <string>
+
#include "ccall.cpp"
//Mark our stats as being from intrinsics irgen fixes compilation of |
@mofeing thank you for your work! One note from my side is that we aim to support the lastest LLVM version used by the latest Julia release for 1.10 that would be LLVM15. The goal is to be able to build for LLVM 15 without too many issues to be able to check where regressions came from. This means that you may need to guard your changes under a |
# Try to find a symbol from the C API of libLLVM as a simple sanity check. | ||
@test dlsym(libLLVM_jll.libLLVM_handle, :LLVMContextCreate; throw_error=false) !== nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vchuravy Not sure how to make this code compatible with LLVM 15 back again. Is there some way to check the version of libLLVM_jll
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't LLVMContextCreate
available in LLVM 15? When I blamed that function I found it was introduced 15 years ago.
Understood! I've refactored the code to include some |
…balVariable(...)`
Good news: #54113 did fix a large chunk of failing packages, now we're down from 103 to 40 failing tests, only 17 of which started failing on this PR. Most common error now seems to be (e.g. PreallocationTools.jl)
Anyone got a clue? 😁 |
@nanosoldier |
I think you missed the first line of the error
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Performance looks good! |
|
Seems to hit the same error in IRCE as most of the CR-verse packages do, but doesn't have a llvmcall warning TidierDB StringAlgorithms |
The string algorithms one is a known LLVM bug sigh. It's llvm/llvm-project#63984 #50453 |
StrBase minimization ;) function containsnul(d)
b = Base.bitcast(Ptr{UInt}, getfield(d, :ptr))
c, e = b,b
while (c += 8) <= e
f end
end
containsnul(Memory{UInt}(undef,1)) |
I wouldn't worry about them too much Maybe knowing what the issue is in particular, e.g. is it the opaque pointer change, might be worth knowing. |
Unfortunately/Fortunately this seems to be an LLVM bug target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128-ni:10:11:12:13"
target triple = "x86_64-unknown-linux-gnu"
define void @julia_containsnul_1() {
top:
br label %L3
L3: ; preds = %L13, %top
%value_phi = phi ptr [ null, %top ], [ %0, %L13 ]
%0 = getelementptr i8, ptr %value_phi, i64 8
%.not = icmp ule ptr %value_phi, null
br i1 %.not, label %L13, label %L15
L13: ; preds = %L3
br label %L3
L15: ; preds = %L3
ret void
}
|
Opened issue upstream llvm/llvm-project#89959 |
@gbaraldi Is that a minimal reproducer from LoopVectorization.jl? |
That is from StrBase, not sure if the patch will fix the LV issue |
@nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
@nanosoldier |
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
The package evaluation job you requested has completed - possible new issues were detected. |
Ensure that when an AnnotatedIOBuffer is wrapped in an IOContext (or similar AnnotatedPipe-based construct), that writes of annotated strings/chars and reading out an AnnotatedString is unimpeded by the IOContext wrapping. Without these specialisations, the generic pipe_reader/pipe_writer fallbacks will directly access the underlying IOBuffer and annotations will be lost. There are a number of scenarios in which one might want to combine an AnnotatedIOBuffer and IOContext (for example setting the compact property). Losing annotations in such scenarios is highly undesirable. It is of particular note that this can arise in situations where you can't unwrap the IOContext as needed, for example when passing IO to a function you do not control (which is currently extremely hard to work around). Getting this right is a little difficult, and a few approaches have been tried. Initially, I added IOContext{AnnotatedIOBuffer} specialisations to show.jl, but arguably it's a bit of a code smell to specialise in this way (and Jameson wasn't happy with it, with concerns that it could be tricked by IOContext{Any}). # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::IOContext{AnnotatedIOBuffer}, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(io.io, s) write(io::AnnotatedIOBuffer, c::AnnotatedChar) = write(io.io, c) Then I tried making it so that IOContext writes dispatched on the wrapped IO type, but of course that broke cases like IOContext{IOBuffer} with :color=>true. # So that read/writes with `IOContext` (and any similar `AbstractPipe` wrappers) # work as expected. write(io::AbstractPipe, s::Union{AnnotatedString, SubString{<:AnnotatedString}}) = write(pipe_writer(io), s) write(io::AbstractPipe, c::AnnotatedChar) = write(pipe_writer(io), c) Finally, we have the current AbstractPipe + Annotated type specialisation, which IOContext is just an instance of. To avoid behaving too broadly, we need to confirm that the underlying IO is actually an AnnotatedIOBuffer. I'm still not happy with this, only idea I've had other than implementing IOContext{AnnotatedIOBuffer} methods that actually seems viable, and I've had trouble soliciting help from other people brainstorming here. If somebody can implement something cleaner here in the future, I'd be thrilled.
No description provided.