Backports for 1.2.0 release #32592
Backports for 1.2.0 release #32592
Conversation
…artesian coordinates (#32007) Revert "sparse findnext findprev hash performance improved (#31354)" This seems to duplicate work from #23317 and it causes performance degradation in the cases that one was designed for. See #31354 (comment) This reverts commit e0bef65. Thanks to @mbauman for spotting this issue in #32007 (comment). (cherry picked from commit ec797ef)
KristofferC
added
needs nanosoldier run
|
Might as well backport #32054 if the branding also got backported ? |
|
Yes that would be a good idea. |
The bug here is a bit subtle, but perhaps best illustrated with
the included test case:
```
function f32579(x::Int64, b::Bool)
if b
x = nothing
end
if isa(x, Int64)
y = x
else
y = x
end
if isa(y, Nothing)
z = y
else
z = y
end
return z === nothing
end
```
The code just after SSA conversion looks like:
```
2 1 ─ goto #3 if not _3
3 2 ─ %2 = Main.nothing::Core.Compiler.Const(nothing, false)
5 3 ┄ %3 = φ (#2 => %2, #1 => _2)::Union{Nothing, Int64}
│ %4 = (%3 isa Main.Int64)::Bool
└── goto #5 if not %4
6 4 ─ %6 = π (%3, Int64)
└── goto #6
8 5 ─ %8 = π (%3, Nothing)
10 6 ┄ %9 = φ (#4 => %6, #5 => %8)::Union{Nothing, Int64}
│ %10 = (%9 isa Main.Nothing)::Bool
└── goto #8 if not %10
11 7 ─ %12 = π (%9, Nothing)
└── goto #9
13 8 ─ %14 = π (%9, Int64)
15 9 ┄ %15 = φ (#7 => %12, #8 => %14)::Union{Nothing, Int64}
│ %16 = (%15 === Main.nothing)::Bool
└── return %16
```
Now, we have special code in SROA (despite it not really being an
SROA transform) that looks at `===` and replaces
it by a nest of phis of booleans. The reasoning for this transform
is that it eliminates a use of a value where we only care about the
type and not the content, thus making it more likely that the value
will subsequently be eligible for SROA. In addition, while it goes
along resolving which values feed into any particular phi, it
accumulates and type conditions it encounters along the way.
Thus in the example above, something like the following happens:
- We look at %14, which πs to %9 with an Int64 constraint, so we only
consider the #4 predecessor for %9 (due to the constraint), until
we get to %3, where we again only consider the #1 predecessor,
where we find the argument (of type Int64) and conclude the result
is always false
- Now we pop the next item of the stack from our original phi, look
at %12, which πs to %9 with a Nothing constraint.
At this point we used to terminate the search because we already looked
at %9. However, crucially, we looked at %9 only with an Int64 constraint,
so we missed the fact that `nothing` was in fact a possible value for this
phi. The result was a missing entry in the generated phi node:
```
1 ─ goto #3 if not b
2 ─ %2 = Main.nothing::Core.Compiler.Const(nothing, false)
3 ┄ %3 = φ (#1 => false)::Bool
│ %4 = φ (#2 => %2, #1 => _2)::Union{Nothing, Int64}
│ %5 = (%4 isa Main.Int64)::Bool
└── goto #5 if not %5
4 ─ %7 = π (%4, Int64)
└── goto #6
5 ─ %9 = π (%4, Nothing)
6 ┄ %10 = φ (#4 => %3, #5 => %3)::Bool
│ %11 = φ (#4 => %7, #5 => %9)::Union{Nothing, Int64}
│ %12 = (%11 isa Main.Nothing)::Bool
└── goto #8 if not %12
7 ─ goto #9
8 ─ nothing::Nothing
9 ┄ %16 = φ (#7 => %10, #8 => %10)::Bool
└── return %16
```
(note the missing #2 predecessor in phi node %3), which would result
in an undefined value at runtime, though in this case LLVM would
have taken advantage of that to just return 0:
```
define i8 @julia_f32579_16051(i64, i8) {
top:
; @ REPL[1]:15 within `f32579'
ret i8 0
}
```
Compare this now to the optimized IR with this patch:
```
1 ─ goto #3 if not b
2 ─ %2 = Main.nothing::Core.Compiler.Const(nothing, false)
3 ┄ %3 = φ (#2 => true, #1 => false)::Bool
│ %4 = φ (#2 => %2, #1 => _2)::Union{Nothing, Int64}
│ %5 = (%4 isa Main.Int64)::Bool
└── goto #5 if not %5
4 ─ %7 = π (%4, Int64)
└── goto #6
5 ─ %9 = π (%4, Nothing)
6 ┄ %10 = φ (#4 => %3, #5 => %3)::Bool
│ %11 = φ (#4 => %7, #5 => %9)::Union{Nothing, Int64}
│ %12 = (%11 isa Main.Nothing)::Bool
└── goto #8 if not %12
7 ─ goto #9
8 ─ nothing::Nothing
9 ┄ %16 = φ (#7 => %10, #8 => %10)::Bool
└── return %16
```
The %3 phi node has its missing entry and the generated LLVM code
correctly returns `b`:
```
define i8 @julia_f32579_16112(i64, i8) {
top:
%2 = and i8 %1, 1
; @ REPL[1]:15 within `f32579'
ret i8 %2
}
```
(cherry picked from commit 0a12944)
* Fix jl_obvious_subtype with INT vararg constraint
* Fix a vararg-related non-transitivity in subtyping
* Fix another vararg subtype issue
* Take advantage of their being at most one UnionAll wrapped around a Vararg
Upon construction, we normalize `Vararg{T, N} where {T,N}` to `Vararg{T where T, N} where N`,
thus there can be at most one UnionAll wrapper around a Vararg. In subtyping we were already
assuming that there can be at most two such wrappers, so simply adjust that and add an
appropriate assertion to make sure we catch any cases where this ever goes wrong.
* Rewrite subtype_tuple to fix extra cases
* Put back the case for naked varargs
* Update test/subtype.jl
Co-Authored-By: Keno <keno@alumni.harvard.edu>
* Add test for #31805
* Fix style review comments
* Rename variable
* In person review changes
* Fix bug
* Handle integer bounds on left arguments in the environment
In subtyping proper, variables introduced on the left (i.e. forall
variables) don't have any equality constraints, because we have no
syntax for creating them. However, intersection does sometimes create
such environments, so we need to handle it in subtyping.
(Cherry-picked from 4a38e79)
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
This comment has been minimized.
This comment has been minimized.
|
The DataFrames.jl failure looks like #32607 |
ararslan
removed
the
needs nanosoldier run
|
The Cbc issue was addressed in jump-dev/Cbc.jl#115 and made it into a tag but it's still failing with the same error. |
|
Regarding Cbc, they directly include a test from another package which happens to use Compat: https://github.com/JuliaOpt/Cbc.jl/blob/8fe080bdc21265c7b4b14c39c70c8848823927a8/test/MPB_wrapper.jl#L5 so they do need Compat... |
|
Fix for Cumulants: iitis/Cumulants.jl#14 |
|
Fix for Cbc: jump-dev/Cbc.jl#118 |
|
Looks like BlackBoxOptim and HypothesisTests are broken by printing changes |
|
MLDataPattern is the same as previous runs: #31727 (comment) cc @Evizero |
|
UnicodePlots issue persists: #31727 (comment) |
|
NearestNeighborDescent also seems like an inference regression. |
|
FYI: robertfeldt/BlackBoxOptim.jl#128 should fix the PkgEval failure |
|
PolynomialRings and StrBase are new method ambiguities. |
Backport 32054
|
It seems like the possibly interesting ones there to look into more closely are: |
|
I don't think SQLite is actually a problem; it uses serialization for custom types, so if anything gets tweaked there, it breaks. |
|
I've edited my comment above with the results of a run which does not skip packages for which a dependency fails tests. I went through and checked off the usual suspects from earlier and submitted a bunch of PRs to fix the new minor things. There are a couple of failures I don't understand in addition to the ones Jameson noted above. |
|
Rotations: just some changed printing |
|
ArnoldiMethod: is getting different numbers. Needs to be looked at by somebody who knows about numbers. |
|
QuantumLattices: some block expression now includes a location that didn't previously |
|
RandomMatrices: also different numbers |
|
GPUifyLoops: Needs a test dependency on InteractiveUtils? |
|
IntervalArithmetic: Inference widened to Any |
|
Dolang and SolverTools both reduced to this intersection regression: edit: bisected to 0d9c72d |
|
IntervalArithmetic is a known package issue (JuliaIntervals/IntervalArithmetic.jl#291) |
|
#32592 (comment) fixed GPUifyLoops |
|
According to @andreasnoack, ArnoldiMethod |
|
ArnoldiMethod failures are fixed by https://github.com/haampie/ArnoldiMethod.jl/pull/99 |
|
Ok, great. In that case I think we're ready to merge this and put out the next RC, which I have high hopes will be final. |
|
We should backport #32853 first. Also note that LanguageServer seems like it could be a real regression. |
) (cherry picked from commit 5dbcf20)
|
I think LanguageServer is fixed: julia-vscode/LanguageServer.jl#372 |
|
Excellent! I looked at MatrixNetworks but couldn't figure out what the deal was, and I think that's the last unchecked item. |
|
Master of |
|
You're right, MatrixNetworks master passes locally for me on this branch. Thanks! |
ararslan
removed
DO NOT MERGE
ararslan
changed the title
|
We put quite a lot of commits here without a nanosoldier run, so running one here. @nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
Backported PRs:
forinsidedoinside call #32476 - fix Parsing issue when using threads macro #32467, parsing macro onforinsidedoinside call=== nothingis not== nothingwith--code-coverage=user#32579 - Issue in typeconstraint accumulationNeed manual backport:
Non-merged PRs with backport label: