Bump LLVM to v19.1.7+0 #56130
Bump LLVM to v19.1.7+0 #56130
Conversation
Zentrik
added
compiler:llvm
Zentrik
force-pushed
the
llvm-19-actual
branch
from
c1900d0 to
adc7db4
Compare
|
The EDIT: gcc is giving a slightly different warning on CI but likely a bug as well |
|
In that case you can guard the offending line with something like #pragma GCC diagnostic push
#if defined(_COMPILER_GCC_) && __GNUC__ >= 12 // if this is version-dependent
// Explain why this is being ignored...
#pragma GCC diagnostic ignored "-Wstringop-overflow"
#endif
...
#pragma GCC diagnostic pop |
|
Also, all tests are passing already on aarch64-darwin 🥳 |
|
Looks like the only two issues are a incorrect warning during the build (mose's suggestion doesn't seem to work though |
|
Guessing the asan problem is |
Without the push-and-pop, that becomes closer to just adding Lines 23 to 25 in 80e60c8 |
Zentrik
force-pushed
the
llvm-19-actual
branch
2 times, most recently
from
5c3c307 to
24f4d93
Compare
|
Looks like remaining issue is some failures in |
giordano
added
the
needs pkgeval
|
Second analyzegc failure looks incorrect, it seems to incorrectly think |
|
@nanosoldier |
|
Need to rebase on master now that #56133 has been merged. |
Zentrik
force-pushed
the
llvm-19-actual
branch
2 times, most recently
from
f6b2376 to
e12026f
Compare
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
FWIW, the standard way to deal with this is to add an assert and a comment, as that will make both reviewers and bots happy |
|
The %12 = select i1 %exactly_isa.not, float -0.000000e+00, float %immutable_union.sroa.0.0.copyload, !dbg !77
%value_phi6 = fadd float %value_phi, %12, !dbg !77to %12 = fadd float %value_phi, %immutable_union.sroa.0.0.copyload, !dbg !77
%value_phi6 = select i1 %exactly_isa.not, float %value_phi, float %12, !dbg !77prevents the loopvectorize pass from SIMDing the code. I suspect the other regression for the union.array benchmarks are similar. |
|
I'll try rebasing on top of #52850 and see if that fixes the regressions. |
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. |
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
|
looks like there are a few 8x (vectorization probably) regressions here. |
Locally I get:
```
In file included from /home/rag/Documents/Code/julia/usr/include/llvm/Object/ObjectFile.h:18,
from /home/rag/Documents/Code/julia/usr/include/llvm/DebugInfo/DIContext.h:18,
from /home/rag/Documents/Code/julia/src/debuginfo.cpp:6:
In function 'bool llvm::operator==(llvm::StringRef, llvm::StringRef)',
inlined from 'bool llvm::operator!=(llvm::StringRef, llvm::StringRef)' at /home/rag/Documents/Code/julia/usr/include/llvm/ADT/StringRef.h:874:71,
inlined from 'objfileentry_t find_object_file(uint64_t, llvm::StringRef)' at /home/rag/Documents/Code/julia/src/debuginfo.cpp:948:43,
inlined from 'bool jl_dylib_DI_for_fptr(size_t, llvm::object::SectionRef*, int64_t*, llvm::DIContext**, bool, bool*, uint64_t*, void**, char**, char**)' at /home/rag/Documents/Code/julia/src/debuginfo.cpp:1135:34:
/home/rag/Documents/Code/julia/usr/include/llvm/ADT/StringRef.h:871:20: warning: 'int __builtin_memcmp_eq(const void*, const void*, long unsigned int)' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread]
871 | return ::memcmp(LHS.data(), RHS.data(), LHS.size()) == 0;
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/rag/Documents/Code/julia/src/debuginfo.cpp: In function 'bool jl_dylib_DI_for_fptr(size_t, llvm::object::SectionRef*, int64_t*, llvm::DIContext**, bool, bool*, uint64_t*, void**, char**, char**)':
/home/rag/Documents/Code/julia/src/debuginfo.cpp:1133:11: note: source object allocated here
1133 | fname = dlinfo.dli_fname;
```
On CI:
```
In file included from /cache/build/builder-amdci4-2/julialang/julia-master/usr/include/llvm/Object/ObjectFile.h:18,
from /cache/build/builder-amdci4-2/julialang/julia-master/usr/include/llvm/DebugInfo/DIContext.h:18,
from /cache/build/builder-amdci4-2/julialang/julia-master/src/debuginfo.cpp:6:
In function 'bool llvm::operator==(llvm::StringRef, llvm::StringRef)',
inlined from 'bool llvm::operator!=(llvm::StringRef, llvm::StringRef)' at /cache/build/builder-amdci4-2/julialang/julia-master/usr/include/llvm/ADT/StringRef.h:874:71,
inlined from 'objfileentry_t find_object_file(uint64_t, llvm::StringRef)' at /cache/build/builder-amdci4-2/julialang/julia-master/src/debuginfo.cpp:943:43,
inlined from 'bool jl_dylib_DI_for_fptr(size_t, llvm::object::SectionRef*, int64_t*, llvm::DIContext**, bool, bool*, uint64_t*, void**, char**, char**)' at /cache/build/builder-amdci4-2/julialang/julia-master/src/debuginfo.cpp:1126:47:
/cache/build/builder-amdci4-2/julialang/julia-master/usr/include/llvm/ADT/StringRef.h:871:20: error: 'int __builtin_memcmp_eq(const void*, const void*, long unsigned int)' specified size 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
871 | return ::memcmp(LHS.data(), RHS.data(), LHS.size()) == 0;
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
The change to `GCChecker.cpp` is so the static analyzer doesn't see e.g. a call to a function pointer in llvm and then complain that it might be a safepoint.
e7698a13e319a9919af04d3d693a6f6ea7168a44 isn't in llvm 19
This reverts commit 2252e89.
Zentrik
force-pushed
the
llvm-19-actual
branch
from
d5c0a02 to
b71c902
Compare
|
@nanosoldier |
|
@nanosoldier |
Zentrik
removed
the
needs pkgeval
Seems concerning |
|
Uhm, tests were passing in https://buildkite.com/julialang/julia-master/builds/43624 (c5266cb), and also in https://buildkite.com/julialang/julia-master/builds/43988 (b6f4ada), apart from the analyzegc check. At least that one is working now 😅 |
|
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. Report summary❗ Packages that crashed7 packages crashed only on the current version.
110 packages crashed on the previous version too. ✖ Packages that failed12 packages failed only on the current version.
1941 packages failed on the previous version too. ✔ Packages that passed tests13 packages passed tests only on the current version.
4732 packages passed tests on the previous version too. ~ Packages that at least loaded2 packages successfully loaded only on the current version.
2559 packages successfully loaded on the previous version too. ➖ Packages that were skipped altogether2 packages were skipped only on the current version.
918 packages were skipped on the previous version too. |
|
NIfTI failure is a llvm bug, llvm/llvm-project#127128. While the linked issue is a bug since llvm 18, it only triggers on NIfTI since 19. See https://godbolt.org/z/4TqdcnEs7. |
Ok these don't seem to be llvm 19 issues, similar problem here https://buildkite.com/julialang/julia-master/builds/44889#01951472-9479-4ffc-bbdc-470530837d24/1091-1402. On slack, Jameson says this is possibly due to CI running with multiple threads. |
Including #55650 till that's merged.