Bump LLVM to v17 #53070
Bump LLVM to v17 #53070
Conversation
giordano
added
domain:building
|
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 irgenfixes compilation of |
giordano
force-pushed
the
bump-llvm17
branch
3 times, most recently
from
5a29c44
to
e322f81
Compare
|
@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.
@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.
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(...)`
|
The package evaluation job you requested has completed - possible new issues were detected. |
|
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.