-
-
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
upgrade LLVM to 10 #35318
upgrade LLVM to 10 #35318
Conversation
174ecd2
to
8ae92cc
Compare
This might be the first upgrade where Windows passes at the first attempt... @Keno can I bother you with updating the GCAnalyzer? |
What’s the current thinking on when this might merge? Just wondering, regarding llvm support for new arm cpus related to #36485, a few of which were added in 10. I guess it’d need performance benchmarking given the feared 10% that hit rust https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html |
My current thinking is to wait of 10.0.1 or 11, but yes additional performance benchmarking of the compile time would be good. |
Also #35460 needs to be fixed first. @ianshmean if you want to try your hand at writing an LLVM patch ;) |
I'm happy to take a look in some of my fun time. Can't promise much though.. @vchuravy would you mind rebasing this? |
.... How many relocator does LLVM have = = ....... |
8ae92cc
to
8367e44
Compare
|
Well, I assume they are not "competing"..... Just that I felt like I've fixed a more complex aarch64 relocatioin before, and it's definitely not either Is there an LLVM IR that triggers this? That'll make testing significantly easier. edit: ah, found the ppc one in #35460 |
Is there a patch for this (#35460) already? I finally have a (actually 2) working aarch64 systems again so if no one is working on it I can. |
No patch that I am aware off. |
8367e44
to
df48eb2
Compare
I did some timings on my laptop (so take it with a grain of salt) TLDR| Task | LLVM Version | Time in opt | Total time | Timing compilation of baseLLVM 10Make.user
.ji generation
.o generation
LLVM 9.ji generation
.o generations
|
Would LLVM 11 be an option for Julia 1.6? RC-2 is out now, with 11-final planned for August 26th. I believe LLVM 11 also includes this: https://reviews.llvm.org/D75016 BTW, not particularly relevant to this issue, but the AVX-512 down-clocking problem has been almost complete solved as of Ice Lake: https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html Instructions: scalar/light128 bit - heavy 256 bit - heavy 512 bit I haven't found out how to use |
I assume you mean It's not an LLVM command line option but a (global and per-function) target property. Add |
Yes, perfect, thanks! |
@chriselrod I was thinking the same. Getting to LLVM 11 in 1.6 seems like a good idea on the face of it. 10 does seem to be the ugly duckling and the work on speed since does seem positive, but probably still a good idea to work through 10 to get to 11? There's also some newer arm chip support in LLVM 11 such as nvidia Carmel that would be nice to get into the next LTS. |
It may be the ugly duckling, but I did notice some improvements in several LoopVectorization examples, where integer/indexing code was handled better by LLVM 10 than by LLVM <=9. So there're some definite improvements (that probably apply to other examples as well?). A simple example of where 256-bit performs much better than 512-bit: julia> function trmv!(y, A, x)
fill!(y, 0)
@inbounds for n ∈ axes(A,2)
@simd for m ∈ 1:n
y[m] += A[m,n] * x[n]
end
end
end
trmv! (generic function with 1 method)
julia> M = 64; C = rand(M, M); x = rand(M); y = similar(x);
julia> @benchmark trmv!($y, $C, $x)
BenchmarkTools.Trial:
memory estimate: 0 bytes
allocs estimate: 0
--------------
minimum time: 825.942 ns (0.00% GC)
median time: 830.907 ns (0.00% GC)
mean time: 838.359 ns (0.00% GC)
maximum time: 1.315 μs (0.00% GC)
--------------
samples: 10000
evals/sample: 86 Versus starting with julia> function trmv!(y, A, x)
fill!(y, 0)
@inbounds for n ∈ axes(A,2)
@simd for m ∈ 1:n
y[m] += A[m,n] * x[n]
end
end
end
trmv! (generic function with 1 method)
julia> M = 64; C = rand(M, M); x = rand(M); y = similar(x);
julia> @benchmark trmv!($y, $C, $x)
BenchmarkTools.Trial:
memory estimate: 0 bytes
allocs estimate: 0
--------------
minimum time: 508.031 ns (0.00% GC)
median time: 509.016 ns (0.00% GC)
mean time: 509.541 ns (0.00% GC)
maximum time: 668.363 ns (0.00% GC)
--------------
samples: 10000
evals/sample: 193 FWIW, replacing |
Note that this is LLVM 10.0.1 so lots of fixes might already been backported. Going to LLVM 11 is feasible, but higher risk and might involve more work from our side to side out regressions. If you really want to see LLVM 11 for 1.6 I would appreciate help with that. Getting an WIP on Yggdrasil for rc2 would be the first step, as well as looking at the patch list. Currently I do these upgrades when I am plagued by insomnia. |
I've read a lot of LLVM IR, but that's very different from being familiar with LLVM itself. What's the procedure for these upgrades, how I would I start? Which patch list? Julia's list of LLVM patches, to see which are no longer needed in LLVM 11? |
df48eb2
to
623a767
Compare
623a767
to
91a1abb
Compare
91a1abb
to
9adcdd4
Compare
@nanosoldier |
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
Definitely worth looking into |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
and so it goes, on and on and on. We might either do it now and iron out the kinks
during 1.5 or do it very early in 1.6.