Backports for 1.12.0 / 1.12.1 #59705
Open
+151
−37
Conversation
This file contains hidden or 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
…59631) Setting world bounds on the created `CodeInfo` allows us to interpret opaque closures faster. Taking the following example: ```julia julia> f(x, y) = x + y f (generic function with 1 method) julia> ir = Base.code_ircode_by_type(Tuple{typeof(f), Int, Int})[1][1] 1 1 ─ %1 = intrinsic Base.add_int(_2, _3)::Int64 │╻ + └── return %1 ││ julia> ir.argtypes[1] = Tuple{} Tuple{} julia> oc = Core.OpaqueClosure(ir; do_compile=true) (::Int64, ::Int64)->◌::Int64 ``` this is what we emitted before ```julia julia> @code_typed oc(1, 2) Pair{Core.CodeInfo, Any}(CodeInfo( @ REPL[8]:1 within `f` ┌ @ int.jl:87 within `+` 1 ─│ %1 = dynamic Base.add_int(none@_2, none@_3)::Int64 └──│ return %1 └ ), Int64) julia> using BenchmarkTools; @Btime $oc(1, 2) 39.765 ns (0 allocations: 0 bytes) ``` and now: ```julia julia> @code_typed oc(1, 2) Pair{Core.CodeInfo, Any}(CodeInfo( @ REPL[93]:1 within `f` ┌ @ int.jl:87 within `+` 1 ─│ %1 = intrinsic Base.add_int(none@_2, none@_3)::Int64 └──│ return %1 └ ), Int64) julia> using BenchmarkTools; @Btime $oc(1, 2) 2.678 ns (0 allocations: 0 bytes) ``` The overhead notably adds more and more with every statement, which for ~20 statements led to > 1 µs of overhead, and multiple allocations. This overhead is observed on 1.12+ only (1.11 evaluates as fast as with this change), which may have been surfaced by the partitioned bindings feature. (cherry picked from commit a5576b4)
Add `gcdx(a::Signed, b::Unsigned)` and `gcdx(a::Unsigned, b::Signed)` methods to fix #58025: ```julia julia> gcdx(UInt16(100), Int8(-101)) # pr (0x0001, 0xffff, 0xffff) julia> gcdx(UInt16(100), Int8(-101)) # master, incorrect result (0x0005, 0xf855, 0x0003) ``` Also add the equivalent methods for `lcm` to fix the systematic `InexactError` when one argument is a negative `Signed` and the other is any `Unsigned`: ```julia julia> lcm(UInt16(100), Int8(-101)) # pr 0x2774 julia> lcm(UInt16(100), Int8(-101)) # master, error ERROR: InexactError: trunc(UInt16, -101) Stacktrace: [1] throw_inexacterror(func::Symbol, to::Type, val::Int8) @ Core ./boot.jl:866 [2] check_sign_bit @ ./boot.jl:872 [inlined] [3] toUInt16 @ ./boot.jl:958 [inlined] [4] UInt16 @ ./boot.jl:1011 [inlined] [5] convert @ ./number.jl:7 [inlined] [6] _promote @ ./promotion.jl:379 [inlined] [7] promote @ ./promotion.jl:404 [inlined] [8] lcm(a::UInt16, b::Int8) @ Base ./intfuncs.jl:152 [9] top-level scope @ REPL[62]:1 ``` Inspired by #59487 (comment). The difference is that the solution proposed in this PR keeps the current correct result type for inputs such as `(::Int16, ::UInt8)`. (cherry picked from commit 4f1e471)
KristofferC
force-pushed
the
backports-release-1.12
branch
from
2e71e44 to
2907ebd
Compare
|
Can #59063 be added to this list? The changes made in the PR are minimal and fix a rounding bug when converting |
|
I think we can backport it, if there are no particular objections from cc @adienes @oscardssmith. |
|
none here |
|
none |
aviatesk
force-pushed
the
backports-release-1.12
branch
from
acdc210 to
3c7e88b
Compare
Previously, add_ptr and sub_ptr intrinsics were incorrectly inferred as potentially throwing because they fell through to the general primitive type check, which was incorrect after #53687 changed them. This adds explicit handling in intrinsic_exct to return Union{} (nothrow) when given correct argument types (Ptr and UInt), similar to #57398. Fixes #57557 Written by Claude
the comment claims: > When the concrete type of p is signed and has the lowest value, > `p != 0 && p == -p` is equivalent to `p == typemin(typeof(p))` this is true, but fails to consider that `p == -p` is also true when `p = div(typemax(UInt), 2) + 1`, and that `p` is not necessarily signed leading to incorrect results on inputs like ``` julia> powermod(0x03, 0x80, 0x07) 0x01 ``` which should be `0x02` (cherry picked from commit bb3be0d)
Fixes #44679 Co-authored-by: KristofferC <[email protected]> (cherry picked from commit 65ef689)
maxsize is usually typemax, so need to be careful to not do comparisons after adding to it. Substracting from it should normally be perfectly fine. At worst we should compute a negative amount of space remaining. (cherry picked from commit 85687b5)
(cherry picked from commit 47908c8)
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:
CodeInfocreated forOpaqueClosure(::IRCode)#59631Core._svec_len#59706abstract_eval_nonlinearized_foreigncall_name#59722Need manual backport:
macroexpand!function and addlegacyscopekwarg #59276:to makereshapetrimmable #59598Contains multiple commits, manual intervention needed:
CoreLogging: prevent someAnnotated*-related instability #59467Non-merged PRs with backport label:
powermodcorrectness on unsigned power of half typemax #59680prevfloatwith unsigned stepcount #59668maxthreadidfromThreads#57490