Backports for Julia 1.4 RC2 #34517
Merged
Backports for Julia 1.4 RC2 #34517
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KristofferC
added
status:DO NOT MERGE
|
@nanosoldier |
|
Your test job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
These should probably be using `samefile`, if they were real code instead of just tests. Though it's unclear why real code would be doing this. Maybe just don't put your paths in hash-tables and you'll normally be fine. (cherry picked from commit a5c422f)
[release-1.4] Bump OpenBLAS BB tarball version and update checksums
(cherry picked from commit 54c1667)
(cherry picked from commit aa13637)
(cherry picked from commit 181050b)
…(<=3.8) (#34490) LLVM <= 3.8 segfaults when LLVM SIMD vectors are not powers of 2 (or a sum of 2 different powers of 2). This LLVM bug was corrected in 2017 (see <https://bugs.llvm.org/show_bug.cgi?id=27708>). This change removes this work-around, finally allowing arbitrary SIMD vector lengths in Julia. This changes Julia's ABI for SIMD types. All SIMD types are now represented as SIMD vectors in LLVM. The work-around represented some SIMD types as LLVM arrays instead to avoid the LLVM segfault. I don't think that SIMD vector lengths that are not a power of 2 were in widespread use, if at all. (cherry picked from commit e0740fe)
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes #32414 (cherry picked from commit 268ac24)
* Construct MulAddMul at gemm_wrapper! call sites * Add branches manually in MulAddMul constructor This is suggested by chethega in: #29634 (comment) * Update stdlib/LinearAlgebra/src/generic.jl Co-Authored-By: Kristoffer Carlsson <kristoffer.carlsson@chalmers.se> Co-authored-by: Kristoffer Carlsson <kristoffer.carlsson@chalmers.se> (cherry picked from commit 2da42e0)
* make package cache interit permission from source * remove temporary directries (cherry picked from commit 5075472)
KristofferC
force-pushed
the
backports-release-1.4
branch
from
e753b3e
to
3a22e2f
Compare
Vectorized loads can come in 3 variants: - scalar - masked - gather All work about the same--if we run into a Loaded pointer, we need to follow back the base pointer and track it. And otherwise they're just normal def/use statements. But we also need to fix up after an LLVM mistake and put a valid value in the pass-through slot. Co-authored-by: Jameson Nash <vtjnash@gmail.com> (cherry picked from commit 7d1c925)
Even non LoadInst / StoreInst (esp. vectorized loads and stores) can have this information (cherry picked from commit 40d0bc5)
|
@nanosoldier |
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
|
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
KristofferC
force-pushed
the
backports-release-1.4
branch
from
c7ba7f3
to
27d2693
Compare
|
Actually, looking into this, we don't need to backport #34787. This branch works just fine with LLVM assertions as-is. I do find it a little bit weird that you need to set |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Add LLVM asserts checksums
(cherry picked from commit b0d1c1a)
When there is no work to do, the first thread to be idle will attempt to run the event loop once, waiting for any notifications (which will usually create new work). However, there is an interesting corner case where a notification arrives, but no work was scheduled. That doesn't usually happen, but there are a few situations where it does: 1) Somebody used a libuv primitive outside of julia, so the callback doesn't schedule any julia work. 2) Another thread forbily interrupted the waiting thread because it wants to take over the event loop for various reasons 3) On Windows, we occasionally get spurious wake ups of the event loop. The existing code in partr assumed that we were in situation 2, i.e. that there was another thread waiting to take over the event loop, so it released the event loop and simply put the current thread to sleep in the expectation that another thread will pick it up. However, if we instead are in one of the other two conditions, there may not be another thread there to pick up the event loop. Thus, with no thread owning the event loop, julia will stop responding to events and effectively deadlock. Since both 1 and 3 are rare, and we don't actually enter the event loop until there was no work for 4 milliseconds (which is fairly rare), this condition rarely happens, but is occasionally observable on Windows, where it caused #34769. To test that this fix works, we manually create situation 1 in the test by creating an idle callback, which will prevent the event loop from blocking, but only schedules julia work after it's been called 100 times. This reproduces the observed failure from the issue and is fixed by this PR. Fixes #34769 Co-authored-by: Jeff Bezanson <jeff@juliacomputing.com> Co-authored-by: Jameson Nash <jameson@juliacomputing.com> (cherry picked from commit f36edc2)
) We were lying to LLVM, and it now catches that in the verifier. Stop lying to LLVM so that it will again be happy to generate good code for us (e.g. optimizing this to bcmp). (cherry picked from commit d634f73)
KristofferC
changed the title
|
This should be good to go ones CI passes. |
|
There is also #34770. |
|
It is not on the milestone. Why is it a blocker? |
|
Agreed; there is a bug fix there but it doesn't seem super critical. |
The `reduced_indices` and `reduced_indices0` methods sometimes assert that the return axes type is the same as the input. Consequently, the implementation of `reduced_index` had better return a range of the same type as the input. This corrects the error in JuliaArrays/OffsetArrays.jl#92. I'll put a workaround in OffsetArrays.jl too. (cherry picked from commit eda4131)
|
Ok, it got merged so I put in the commit in that PR that was asked to be backported. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backported PRs:
@code_nativewith eltype (#34434) #34458 - src/codegen.cpp: fix segfault on@code_nativewith eltype (Segfault calling @code_native on eltype #34434)hypotfallback for 2 Numbers of the same type #34316julia_const_to_llvm#34829 - fix LLVM assertion failure in core tests #34826, unwrap VecElement when needed injulia_const_to_llvmreduced_index#34770 - Convert range type inreduced_index