Skip to main content

Browse the archive

https://github.com/JuliaLang/julia
30 August 2024, 22:04:04 UTC
sort by:
Revision Author Date Message Commit Date
b39bc4f d-netto 06 December 2023, 02:42:04 UTC started to implement object age instrumention on pool allocator 07 December 2023, 11:37:40 UTC
c731edb Shuhei Kadowaki 07 December 2023, 01:57:47 UTC irinterp: skip `nothing` statement when analyzing `:nothrow` and `:noub` (#52417) This commit makes irinterp skip `nothing` statements when looking through `:nothrow` and `:noub` flags of all statements. This is necessary since `nothing` can be inserted as a dummy node, e.g. to prevent CFG change by `finish_current_bb!`, without explicitly marking it as `IR_FLAG_NOTHROW`. Alternatively, rather than altering irinterp, it might be better to mark `IR_FLAG_NOTHROW` (and maybe even `IR_FLAG_EFFECT_FREE` and other flags too) where those `nothing` statements are inserted. But I wasn't confident that this would address all scenarios or if it's the best way to go, so this commit opts for the previously mentioned symptomatic approach. 07 December 2023, 01:57:47 UTC
bdbee27 Shuhei Kadowaki 06 December 2023, 22:06:48 UTC effects: support callsite `@assume_effects` annotation (#52400) 06 December 2023, 22:06:48 UTC
856e112 Jameson Nash 06 December 2023, 15:35:44 UTC channels: fix memory ordering violation in iterate (#52407) Channel `iterate` calls might miss trailing items without this patch. I have not seen proof of this reaching a failure, but we do appear to be missing this ordering specification in visual review. Should not make a difference to generated code on x86, which already has TSO guaranteed, but may alter optimizations and other CPUs with weaker memory orderings. 06 December 2023, 15:35:44 UTC
3aa943b Jishnu Bhattacharya 06 December 2023, 15:24:51 UTC Sort exported names from LinearAlgebra [nfc] (#52419) 06 December 2023, 15:24:51 UTC
e2af398 Diogo Netto 06 December 2023, 15:12:40 UTC add a test for page utilization metric (#52411) 06 December 2023, 15:12:40 UTC
627210d Daniel Karrasch 06 December 2023, 14:36:51 UTC Return of the `tilebufsize` (#52422) See https://github.com/JuliaLang/julia/pull/52298#discussion_r1417407376. 06 December 2023, 14:36:51 UTC
dbb797f Shuhei Kadowaki 06 December 2023, 14:31:35 UTC add two-arg `@macroexpand[1]` (#52416) So that we can provide a module context to evaluate in. This is more aligned with the design of `@eval` and `Meta.@lower`. 06 December 2023, 14:31:35 UTC
fd9d3c0 Jameson Nash 06 December 2023, 14:15:44 UTC ircode: fix regression (crash) from Memory{T} PR (#52409) The offset should be in elements not bytes. 06 December 2023, 14:15:44 UTC
cfcc043 Jishnu Bhattacharya 06 December 2023, 14:08:22 UTC Aggressive constprop in matvecmul and matmatmul (#51961) 06 December 2023, 14:08:22 UTC
6a1df3d Daniel Karrasch 06 December 2023, 11:20:33 UTC Review annotations and test for allocations in generic matmatmul (#52298) 06 December 2023, 11:20:33 UTC
b5abac4 Jameson Nash 06 December 2023, 05:12:22 UTC delete unused code from simplevector (#52412) Circa #45062 and #46975 06 December 2023, 05:12:22 UTC
a948e6d Lionel Zoubritzky 06 December 2023, 05:10:09 UTC Fix completion hint for sub/superscripts (#52402) Fix #52376 The completion hint starting offset was not computed considering the case where the input and the completion do not share the same prefix, which happens when completing into a subscript or a superscript. This fixes that by iteratively going through the characters of the hint until reaching that which marks the end of the input. 06 December 2023, 05:10:09 UTC
f96585b Shuhei Kadowaki 06 December 2023, 05:03:06 UTC reflection: refactor `@assume_effects` implementation (#52399) I am working on implementing a support for callsite `@assume_effects` annotation, and this update is part of the preparation for that goal. Along this, I've modified the API from `pushmeta!(::Expr, ::Symbol, args...)` to `pushmeta!(::Expr, ::Union{Symbol,Expr})`. This change isn't breaking as long as the `args` are empty, which is the case for most use cases (actually there is only one usage of `pushmeta!` with non-empty `args` within Julia base). I've verified on JuliaHub, and there don't appear to be any packages using `pushmeta!` with non-empty `args`, so there shouldn't be any (big) issues. 06 December 2023, 05:03:06 UTC
2949dd5 Diogo Netto 05 December 2023, 20:40:31 UTC bugfix: make sure symbol loading from Base.gc_page_utilization_data works on linux (#52406) Co-authored-by: Jameson Nash <vtjnash@gmail.com> 05 December 2023, 20:40:31 UTC
4209474 jariji 05 December 2023, 18:24:32 UTC Add `Docs.hasdoc` function (#52139) Add helper method `Docs.hasdoc` to facilitate automated testing of whether documentation exists. Closes: https://github.com/JuliaLang/julia/issues/51174. Co-authored-by: Steven G. Johnson <stevenj@mit.edu> 05 December 2023, 18:24:32 UTC
fd41af5 Sam 05 December 2023, 17:10:25 UTC Add logdet and logabsdet methods for Symmetric/Hermitian matrices (#51930) Co-authored-by: Daniel Karrasch <daniel.karrasch@posteo.de> 05 December 2023, 17:10:25 UTC
e26c257 Diogo Netto 05 December 2023, 16:47:15 UTC GC scheduler refinements (#52294) Supersedes https://github.com/JuliaLang/julia/pull/51061 and https://github.com/JuliaLang/julia/pull/51414. Still needs more perf analysis. 05 December 2023, 16:47:15 UTC
2ef056a Daniel Karrasch 05 December 2023, 15:39:51 UTC Simplify triangular multiplication code slightly (#52393) 05 December 2023, 15:39:51 UTC
dcf08be Jishnu Bhattacharya 05 December 2023, 15:03:12 UTC Declare hermitian/hermitian_type to be public (#52388) Similarly, for `symmetric/symmetric_type`. These are meant to be specialized by custom types, so these should not be marked internal to `LinearAlgebra`. 05 December 2023, 15:03:12 UTC
e0d9cb2 Morten Piibeleht 05 December 2023, 14:55:24 UTC Update Documenter 0.27.23 => 1.2.1 (#47105) Currently mainly to test a few things on CI here, but will update this to an actual PR once 0.28.0 is out. --------- Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com> 05 December 2023, 14:55:24 UTC
d0e7ec0 Jishnu Bhattacharya 05 December 2023, 14:54:41 UTC Adjoint for vectors may use trailing axes of the parent (#52379) Close #52373, or at least the part that may be addressed here. After this, the first axis for an `Adjoint(parent::AbstractVector)` will be the second axis of the `parent`. This will change the type of the axis where the parent array type specializes `axes(A, d)`. In the short term, this would improve type-stability in cases such as ```julia julia> A = OffsetArray([1,2], 2); julia> @code_typed axes(A')[1] CodeInfo( 1 ─ %1 = $(Expr(:boundscheck))::Bool │ %2 = Base.getfield(t, i, %1)::OffsetArrays.IdOffsetRange{Int64, Base.OneTo{Int64}} └── return %2 ) => OffsetArrays.IdOffsetRange{Int64, Base.OneTo{Int64}} ``` where the result is now concretely inferred instead of being a small `Union`. In principle, with https://github.com/JuliaArrays/StaticArrays.jl/pull/916, this would make the axes of the adjoint of a `StaticVector` statically sized. 05 December 2023, 14:54:41 UTC
28b252a Jishnu Bhattacharya 05 December 2023, 14:54:21 UTC Remove confusing `::AdjointAbsVec * ::AdjointAbsVec` methods (#52401) These methods presumably exist to throw an error at the top-level, rather than after the arrays have been unwrapped. However, the error message is confusingly incorrect: ```julia julia> x = [1]'; julia> x isa Adjoint{T, <:AbstractVector} where T true julia> x * x ERROR: MethodError: no method matching *(::LinearAlgebra.Adjoint{Int64, Vector{Int64}}, ::LinearAlgebra.Adjoint{Int64, Vector{Int64}}) Closest candidates are: *(::LinearAlgebra.Adjoint{T, <:AbstractVector} where T, ::LinearAlgebra.Adjoint{T, <:AbstractVector} where T) @ LinearAlgebra ~/packages/julias/julia-latest/share/julia/stdlib/v1.11/LinearAlgebra/src/adjtrans.jl:481 *(::LinearAlgebra.Adjoint{T, <:AbstractVector} where T, ::AbstractMatrix) @ LinearAlgebra ~/packages/julias/julia-latest/share/julia/stdlib/v1.11/LinearAlgebra/src/matmul.jl:87 *(::AbstractMatrix, ::AbstractMatrix, ::Number, ::Number) @ LinearAlgebra ~/packages/julias/julia-latest/share/julia/stdlib/v1.11/LinearAlgebra/src/matmul.jl:1084 ... Stacktrace: [1] *(u::LinearAlgebra.Adjoint{Int64, Vector{Int64}}, v::LinearAlgebra.Adjoint{Int64, Vector{Int64}}) @ LinearAlgebra ~/packages/julias/julia-latest/share/julia/stdlib/v1.11/LinearAlgebra/src/adjtrans.jl:481 [2] top-level scope @ REPL[2]:1 ``` Note that the first suggested method is the one that we're hitting, except this is throwing a `MethodError` again, which makes it seem like there is no match. We may potentially change this from a `MethodError` to a different type (perhaps `ArgumentError`), but perhaps this method is not necessary anyway? After this PR, we obtain ```julia julia> x * x ERROR: MethodError: no method matching *(::Vector{Int64}, ::Vector{Int64}) Closest candidates are: *(::Any, ::Any, ::Any, ::Any...) @ Base operators.jl:595 *(::Dates.Period, ::AbstractArray) @ Dates ~/julia/usr/share/julia/stdlib/v1.11/Dates/src/periods.jl:93 *(::Number, ::AbstractArray) @ Base arraymath.jl:21 ... Stacktrace: [1] *(x::Adjoint{Int64, Vector{Int64}}, A::Adjoint{Int64, Vector{Int64}}) @ LinearAlgebra ~/julia/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/matmul.jl:87 [2] top-level scope @ REPL[9]:1 ``` This makes it clear that the real issue is that we can't multiply two vectors. 05 December 2023, 14:54:21 UTC
9c6fec1 Lilith Orion Hafner 05 December 2023, 14:39:06 UTC Add Zulip to README (#52403) As [suggested](https://github.com/JuliaLang/www.julialang.org/pull/1982#issuecomment-1839772373) by @jariji Placing it above Slack because - Zulip does not eat messages (the slackhole is a drain of community resources, esp. on the #helpdesk channel) - Zulip is FOSS - Zulip is a wee bit more feature complete (this is debatable, but I hold it to be true) 05 December 2023, 14:39:06 UTC
7055644 Jishnu Bhattacharya 05 December 2023, 12:59:58 UTC Unalias off-diagonals in Tridiagonal constructor (#51763) 05 December 2023, 12:59:58 UTC
c1ca0d3 Jishnu Bhattacharya 05 December 2023, 10:59:48 UTC Generalize Diagonal * AdjOrTransAbsMat to arbitrary element types (#52389) 05 December 2023, 10:59:48 UTC
8d0eec9 Aravindh Krishnamoorthy 05 December 2023, 10:37:42 UTC Implement `cbrt(A::AbstractMatrix{<:Real})` (#50661) Co-authored-by: Dilum Aluthge <dilum@aluthge.com> Co-authored-by: Steven G. Johnson <stevenj@mit.edu> 05 December 2023, 10:37:42 UTC
53f1eb8 Steven G. Johnson 05 December 2023, 10:26:21 UTC bugfix for dot of Hermitian{noncommutative} (#52333) Co-authored-by: Daniel Karrasch <daniel.karrasch@posteo.de> 05 December 2023, 10:26:21 UTC
150c1ad Jishnu Bhattacharya 05 December 2023, 10:05:31 UTC Add single-term multiplication for `AbstractQ` on v1.10 and above (#52342) 05 December 2023, 10:05:31 UTC
0a4b810 Diogo Netto 04 December 2023, 20:29:30 UTC functionality to expose page utilization at the julia level (#52390) --------- Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com> 04 December 2023, 20:29:30 UTC
bb7091c matthias314 04 December 2023, 14:58:00 UTC Speed up `first` and `only` for various types (#52296) 04 December 2023, 14:58:00 UTC
f761860 Benjamin Lorenz 04 December 2023, 14:15:02 UTC Export `jl_alloc_array_nd`, re-add and export convenience wrappers (#52248) This is used in an example here in the docs https://docs.julialang.org/en/v1.11-dev/manual/embedding/#Multidimensional-Arrays and needed to adapt to the removed `jl_alloc_array_2d` (#51319). 04 December 2023, 14:15:02 UTC
e280387 Alexis Montoison 04 December 2023, 13:10:54 UTC [LAPACK] Interface lacpy! and add a Julia version copytrito! (#51909) The PR adds a function `lacpy!` to easily copy a triangular part of a square or rectangular dense matrix. 04 December 2023, 13:10:54 UTC
b69398a Jishnu Bhattacharya 04 December 2023, 03:08:55 UTC Integer matrix exponentiation in schurpow (#51992) This improves type-inference by avoiding recursion, as the `A^p` method calls `schurpow` if `p` is a float. After this, the result of `schurpow` is inferred as a small `Union`: ```julia julia> @inferred Union{Matrix{ComplexF64}, Matrix{Float64}} LinearAlgebra.schurpow([1.0 2; 3 4], 2.0) 2×2 Matrix{Float64}: 7.0 10.0 15.0 22.0 ``` One concern here might be that for large `p`, the `A^Int(p)` computation might be expensive by repeated multiplication, as opposed to diagonalization. However, this may only be the case for really large `p`, which may not be commonly encountered. I've added a test, but I'm unsure if `schurpow` is deemed to be an internal function, and this test is unwise. Unfortunately, the return type of `A^p` isn't concretely inferred yet as there are too many possible types that are returned, so I couldn't test for that. 04 December 2023, 03:08:55 UTC
fb5f7ad Joe Greener 04 December 2023, 00:34:19 UTC Fix docs link to package tests docs (#52384) Since https://github.com/JuliaLang/julia/pull/52102 these links to the Pkg.jl docs are dead. This should point them to the new location in the Julia docs. There is a reference in CONTRIBUTING.md that should change as well, but maybe not until a Julia version with these changes is released: https://github.com/JuliaLang/julia/blob/3e4b38684e38a015446253f5752ee9cf840f50cc/CONTRIBUTING.md?plain=1#L17 04 December 2023, 00:34:19 UTC
3e4b386 Shuhei Kadowaki 03 December 2023, 04:15:57 UTC add some comments about `ScopedValue` implementation (#52372) 03 December 2023, 04:15:57 UTC
641f717 Ian Butterworth 02 December 2023, 14:36:18 UTC make custom log macros work (#52359) 02 December 2023, 14:36:18 UTC
aef528d Diogo Netto 01 December 2023, 03:51:11 UTC nfc: remove duplicate variable declaration (#52360) 01 December 2023, 03:51:11 UTC
58c1d51 Shuhei Kadowaki 01 December 2023, 00:12:35 UTC [REPLCompletions] fix #52099 by adjusting effects of `HAMT` methods (#52331) After looking into #52099, I discovered that it has the same root cause as #51548. Essentially, when a method that's not `!effect_free` is applied to a `Const` value concretized by the `REPLInterpreter`'s aggressive inference, since the `!effect_free` method will not be concretized, it will eventually lead to the `Const` representing unexpected object being returned. This commit tries to fix the specific problem reported in #52099 by enhancing the effects of `Base.HAMT` methods, so they're concrete-evaled. Admittedly, this is more of a quick fix than a complete solution, and not the best one, but it was the simplest. A better solution might involve implementing EA's handling of `Memory`-objects that allows the compiler to automatically prove `:effect_free` in more scenarios. But this would need a bigger overhaul, so I plan to tackle it in another PR. 01 December 2023, 00:12:35 UTC
bac3ba5 Keno Fischer 30 November 2023, 03:12:47 UTC Fix oracle count violation in sroa_pass! (#52336) 30 November 2023, 03:12:47 UTC
fd67cb2 Steven G. Johnson 29 November 2023, 21:13:04 UTC incorporate upstream fixes to crc32c.c assembly (#52326) These are a response to [this comment](https://stackoverflow.com/questions/17645167/implementing-sse-4-2s-crc32c-in-software/17646775#comment88832559_17646775) on StackOverflow: > Your asm constraints aren't strictly safe. A pointer in a `"r"` constraint does not imply that the pointed-to memory is also an input. You could just use memory operands (or the `_mm_crc32_u64` intrinsic), but if you want to force the addressing mode you can use a dummy memory operand like `asm("crc32 (%1),%0 " : "+r"(crc0) : "r"(next), "m" (*(const char (*)[24]) pStr) )`;. Inlining or LTO could break this. See [at&t asm inline c++ problem](https://stackoverflow.com/posts/comments/81680441) (which needs an update: pointer-to-array is cleaner than a struct with a flexible array member). The existing test coverage wasn't enough to fully exercise Adler's code, so I added another test. Closes #52325 29 November 2023, 21:13:04 UTC
9bd2432 Keno Fischer 29 November 2023, 05:06:41 UTC cfg_simplify: Fix bug in my bugfix (#52337) The fix in #52323 was not quite correct. Fix that and adjust the test to more accurately reflect the actual issue. 29 November 2023, 05:06:41 UTC
de525af Shuhei Kadowaki 28 November 2023, 17:38:41 UTC extract common code to create a dummy `IRCode` into a utility function (#52329) Simplifies test code. xref: <https://github.com/JuliaLang/julia/pull/52323#pullrequestreview-1751907258>. 28 November 2023, 17:38:41 UTC
68b4587 Lilith Orion Hafner 28 November 2023, 14:39:40 UTC Remove no-op specializations of `only` [NFC] (#52328) An easily merged subset of @matthias314's #52296, separated from that PR at @mkitti's suggestion. I kept the low-but-nonzero value specializations for Tuple and Named tuple which offer better error messages. They may be removed with a future PR that improves the generic error message. To verify this is indeed a no-op ``` @code_llvm only(Ref(4)) @code_llvm only(Ref(nothing)) @code_llvm only('z') @code_llvm only((4,)) @code_llvm only((nothing,)) only((4,2)) @code_llvm only(Array{Int, 0}(undef)) @code_llvm only((;x=3)) only((;)) only((;x=2, y=4)) ``` Before ``` julia> @code_llvm only(Ref(4)) ; Function Signature: only(Base.RefValue{Int64}) ; @ iterators.jl:1563 within `only` define i64 @julia_only_2451({}* noundef nonnull align 8 dereferenceable(8) %"x::RefValue") #0 { top: ; ┌ @ refvalue.jl:59 within `getindex` ; │┌ @ Base.jl:49 within `getproperty` %0 = bitcast {}* %"x::RefValue" to i64* %.x = load i64, i64* %0, align 8 ; └└ ret i64 %.x } julia> @code_llvm only(Ref(nothing)) ; Function Signature: only(Base.RefValue{Nothing}) ; @ iterators.jl:1563 within `only` define void @julia_only_2519({}* noundef nonnull %"x::RefValue") #0 { top: ret void } julia> @code_llvm only('z') ; Function Signature: only(Char) ; @ iterators.jl:1565 within `only` define i32 @julia_only_2527(i32 zeroext %"x::Char") #0 { top: ret i32 %"x::Char" } julia> @code_llvm only((4,)) ; Function Signature: only(Tuple{Int64}) ; @ iterators.jl:1566 within `only` define i64 @julia_only_2529([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::Tuple") #0 { top: ; ┌ @ tuple.jl:31 within `getindex` %"x::Tuple[1]_ptr" = getelementptr inbounds [1 x i64], [1 x i64]* %"x::Tuple", i64 0, i64 0 ; └ %"x::Tuple[1]_ptr.unbox" = load i64, i64* %"x::Tuple[1]_ptr", align 8 ret i64 %"x::Tuple[1]_ptr.unbox" } julia> @code_llvm only((nothing,)) ; Function Signature: only(Tuple{Nothing}) ; @ iterators.jl:1566 within `only` define void @julia_only_2532() #0 { top: ret void } julia> only((4,2)) ERROR: ArgumentError: Tuple contains 2 elements, must contain exactly 1 element Stacktrace: [1] only(x::Tuple{Int64, Int64}) @ Base.Iterators ./iterators.jl:1567 [2] top-level scope @ REPL[6]:1 julia> @code_llvm only(Array{Int, 0}(undef)) ; Function Signature: only(Array{Int64, 0}) ; @ iterators.jl:1570 within `only` define i64 @julia_only_2779({}* noundef nonnull align 8 dereferenceable(16) %"a::Array") #0 { top: ; ┌ @ abstractarray.jl:1314 within `getindex` ; │┌ @ abstractarray.jl:1343 within `_getindex` ; ││┌ @ essentials.jl:817 within `getindex` %0 = bitcast {}* %"a::Array" to i64** %1 = load i64*, i64** %0, align 8 %2 = load i64, i64* %1, align 8 ; └└└ ret i64 %2 } julia> @code_llvm only((;x=3)) ; Function Signature: only(NamedTuple{(:x,), Tuple{Int64}}) ; @ iterators.jl:1571 within `only` define i64 @julia_only_2794([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::NamedTuple") #0 { top: ; ┌ @ abstractarray.jl:469 within `first` ; │┌ @ namedtuple.jl:165 within `iterate` @ namedtuple.jl:165 %"x::NamedTuple.x_ptr" = getelementptr inbounds [1 x i64], [1 x i64]* %"x::NamedTuple", i64 0, i64 0 ; └└ %"x::NamedTuple.x_ptr.unbox" = load i64, i64* %"x::NamedTuple.x_ptr", align 8 ret i64 %"x::NamedTuple.x_ptr.unbox" } julia> only((;)) ERROR: ArgumentError: NamedTuple contains 0 elements, must contain exactly 1 element Stacktrace: [1] only(x::@NamedTuple{}) @ Base.Iterators ./iterators.jl:1572 [2] top-level scope @ REPL[9]:1 julia> only((;x=2, y=4)) ERROR: ArgumentError: NamedTuple contains 2 elements, must contain exactly 1 element Stacktrace: [1] only(x::@NamedTuple{x::Int64, y::Int64}) @ Base.Iterators ./iterators.jl:1572 [2] top-level scope @ REPL[10]:1 ``` After ``` julia> @code_llvm only(Ref(4)) ; Function Signature: only(Base.RefValue{Int64}) ; @ iterators.jl:1550 within `only` define i64 @julia_only_6821({}* noundef nonnull align 8 dereferenceable(8) %"x::RefValue") #0 { top: ; @ iterators.jl:1551 within `only` ; ┌ @ refpointer.jl:103 within `iterate` ; │┌ @ refvalue.jl:59 within `getindex` ; ││┌ @ Base.jl:49 within `getproperty` %0 = bitcast {}* %"x::RefValue" to i64* %.x = load i64, i64* %0, align 8 ; └└└ ; @ iterators.jl:1559 within `only` ret i64 %.x } julia> @code_llvm only(Ref(nothing)) ; Function Signature: only(Base.RefValue{Nothing}) ; @ iterators.jl:1550 within `only` define void @julia_only_6824({}* noundef nonnull %"x::RefValue") #0 { top: ; @ iterators.jl:1559 within `only` ret void } julia> @code_llvm only('z') ; Function Signature: only(Char) ; @ iterators.jl:1550 within `only` define i32 @julia_only_6826(i32 zeroext %"x::Char") #0 { top: ; @ iterators.jl:1559 within `only` ret i32 %"x::Char" } julia> @code_llvm only((4,)) ; Function Signature: only(Tuple{Int64}) ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1566 within `only` define i64 @julia_only_6833([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::Tuple") #0 { top: ; ┌ @ tuple.jl:31 within `getindex` %"x::Tuple[1]_ptr" = getelementptr inbounds [1 x i64], [1 x i64]* %"x::Tuple", i64 0, i64 0 ; └ %"x::Tuple[1]_ptr.unbox" = load i64, i64* %"x::Tuple[1]_ptr", align 8 ret i64 %"x::Tuple[1]_ptr.unbox" } julia> @code_llvm only((nothing,)) ; Function Signature: only(Tuple{Nothing}) ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1566 within `only` define void @julia_only_6836() #0 { top: ret void } julia> only((4,2)) ERROR: ArgumentError: Tuple contains 2 elements, must contain exactly 1 element Stacktrace: [1] only(x::Tuple{Int64, Int64}) @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1564 [2] top-level scope @ REPL[31]:1 julia> @code_llvm only(Array{Int, 0}(undef)) ; Function Signature: only(Array{Int64, 0}) ; @ iterators.jl:1550 within `only` define i64 @julia_only_6848({}* noundef nonnull align 8 dereferenceable(16) %"x::Array") #0 { L60: ; @ iterators.jl:1551 within `only` ; ┌ @ array.jl:884 within `iterate` @ array.jl:884 ; │┌ @ essentials.jl:817 within `getindex` %0 = bitcast {}* %"x::Array" to i64** %1 = load i64*, i64** %0, align 8 %2 = load i64, i64* %1, align 8 ; └└ ; @ iterators.jl:1559 within `only` ret i64 %2 } julia> @code_llvm only((;x=3)) ; Function Signature: only(NamedTuple{(:x,), Tuple{Int64}}) ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1571 within `only` define i64 @julia_only_6871([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::NamedTuple") #0 { top: ; ┌ @ abstractarray.jl:469 within `first` ; │┌ @ namedtuple.jl:165 within `iterate` @ namedtuple.jl:165 %"x::NamedTuple.x_ptr" = getelementptr inbounds [1 x i64], [1 x i64]* %"x::NamedTuple", i64 0, i64 0 ; └└ %"x::NamedTuple.x_ptr.unbox" = load i64, i64* %"x::NamedTuple.x_ptr", align 8 ret i64 %"x::NamedTuple.x_ptr.unbox" } julia> only((;)) ERROR: ArgumentError: NamedTuple contains 0 elements, must contain exactly 1 element Stacktrace: [1] only(x::@NamedTuple{}) @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1568 [2] top-level scope @ REPL[34]:1 julia> only((;x=2, y=4)) ERROR: ArgumentError: NamedTuple contains 2 elements, must contain exactly 1 element Stacktrace: [1] only(x::@NamedTuple{x::Int64, y::Int64}) @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1568 [2] top-level scope @ REPL[35]:1 ``` Diff ```diff < # Before --- > # After 4,5c4,5 < ; @ iterators.jl:1563 within `only` < define i64 @julia_only_2451({}* noundef nonnull align 8 dereferenceable(8) %"x::RefValue") #0 { --- > ; @ iterators.jl:1550 within `only` > define i64 @julia_only_6821({}* noundef nonnull align 8 dereferenceable(8) %"x::RefValue") #0 { 7,11c7,14 < ; ┌ @ refvalue.jl:59 within `getindex` < ; │┌ @ Base.jl:49 within `getproperty` < %0 = bitcast {}* %"x::RefValue" to i64* < %.x = load i64, i64* %0, align 8 < ; └└ --- > ; @ iterators.jl:1551 within `only` > ; ┌ @ refpointer.jl:103 within `iterate` > ; │┌ @ refvalue.jl:59 within `getindex` > ; ││┌ @ Base.jl:49 within `getproperty` > %0 = bitcast {}* %"x::RefValue" to i64* > %.x = load i64, i64* %0, align 8 > ; └└└ > ; @ iterators.jl:1559 within `only` 17,18c20,21 < ; @ iterators.jl:1563 within `only` < define void @julia_only_2519({}* noundef nonnull %"x::RefValue") #0 { --- > ; @ iterators.jl:1550 within `only` > define void @julia_only_6824({}* noundef nonnull %"x::RefValue") #0 { 19a23 > ; @ iterators.jl:1559 within `only` 25,26c29,30 < ; @ iterators.jl:1565 within `only` < define i32 @julia_only_2527(i32 zeroext %"x::Char") #0 { --- > ; @ iterators.jl:1550 within `only` > define i32 @julia_only_6826(i32 zeroext %"x::Char") #0 { 27a32 > ; @ iterators.jl:1559 within `only` 33,34c38,39 < ; @ iterators.jl:1566 within `only` < define i64 @julia_only_2529([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::Tuple") #0 { --- > ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1566 within `only` > define i64 @julia_only_6833([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::Tuple") #0 { 45,46c50,51 < ; @ iterators.jl:1566 within `only` < define void @julia_only_2532() #0 { --- > ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1566 within `only` > define void @julia_only_6836() #0 { 55c60 < @ Base.Iterators ./iterators.jl:1567 --- > @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1564 57c62 < @ REPL[6]:1 --- > @ REPL[31]:1 61,70c66,76 < ; @ iterators.jl:1570 within `only` < define i64 @julia_only_2779({}* noundef nonnull align 8 dereferenceable(16) %"a::Array") #0 { < top: < ; ┌ @ abstractarray.jl:1314 within `getindex` < ; │┌ @ abstractarray.jl:1343 within `_getindex` < ; ││┌ @ essentials.jl:817 within `getindex` < %0 = bitcast {}* %"a::Array" to i64** < %1 = load i64*, i64** %0, align 8 < %2 = load i64, i64* %1, align 8 < ; └└└ --- > ; @ iterators.jl:1550 within `only` > define i64 @julia_only_6848({}* noundef nonnull align 8 dereferenceable(16) %"x::Array") #0 { > L60: > ; @ iterators.jl:1551 within `only` > ; ┌ @ array.jl:884 within `iterate` @ array.jl:884 > ; │┌ @ essentials.jl:817 within `getindex` > %0 = bitcast {}* %"x::Array" to i64** > %1 = load i64*, i64** %0, align 8 > %2 = load i64, i64* %1, align 8 > ; └└ > ; @ iterators.jl:1559 within `only` 76,77c82,83 < ; @ iterators.jl:1571 within `only` < define i64 @julia_only_2794([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::NamedTuple") #0 { --- > ; @ /Users/x/.julia/dev/julia/base/iterators.jl:1571 within `only` > define i64 @julia_only_6871([1 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(8) %"x::NamedTuple") #0 { 91c97 < @ Base.Iterators ./iterators.jl:1572 --- > @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1568 93c99 < @ REPL[9]:1 --- > @ REPL[34]:1 99c105 < @ Base.Iterators ./iterators.jl:1572 --- > @ Base.Iterators ~/.julia/dev/julia/base/iterators.jl:1568 101c107 < @ REPL[10]:1 --- > @ REPL[35]:1 ``` --------- Co-authored-by: matthias314 <matthias314@posteo.net> Co-authored-by: Shuhei Kadowaki <40514306+aviatesk@users.noreply.github.com> 28 November 2023, 14:39:40 UTC
df40bab Hendrik Ranocha 28 November 2023, 12:19:12 UTC fix invalidations related to `ismutable` (#52170) Related to #52134. It would be nice if the underlying inference issue was fixed but this seems to be a hotfix for now. I have seen this inference problem occurring in Julia v1.9, v1.10, and current `master`. For example, on Julia v1.9.3, I get ```julia julia> code_warntype(ismutable, (Function,)) MethodInstance for ismutable(::Function) from ismutable(x) @ Base reflection.jl:521 Arguments #self#::Core.Const(ismutable) x::Function Body::Any 1 ─ nothing │ nothing │ %3 = Base.typeof(x)::Type{<:Function} │ %4 = Base.getproperty(%3, :name)::Any │ %5 = Base.getproperty(%4, :flags)::Any │ %6 = (%5 & 0x02)::Any │ %7 = (%6 == 0x02)::Any └── return %7 ``` This causes some invalidations when `using OrdinaryDiffEq`. 28 November 2023, 12:19:12 UTC
72dbbdb Keno Fischer 28 November 2023, 05:18:39 UTC cfg_simplify: Handle various corner cases with try/catch blocks (#52323) Mostly long-standing bugs related to not handling the virtual predecessor to catch blocks, but also one recent regression from the EnterNode change. 28 November 2023, 05:18:39 UTC
5b2fcb6 Keno Fischer 27 November 2023, 17:01:53 UTC Compiler support for optimizing PersistentDict (#51993) This is part of the work to address #51352 by attempting to allow the compiler to perform SRAO on persistent data structures like `PersistentDict` as if they were regular immutable data structures. These sorts of data structures have very complicated internals (with lots of mutation, memory sharing, etc.), but a relatively simple interface. As such, it is unlikely that our compiler will have sufficient power to optimize this interface by analyzing the implementation. We thus need to come up with some other mechanism that gives the compiler license to perform the requisite optimization. One way would be to just hardcode `PersistentDict` into the compiler, optimizing it like any of the other builtin datatypes. However, this is of course very unsatisfying. At the other end of the spectrum would be something like a generic rewrite rule system (e-graphs anyone?) that would let the PersistentDict implementation declare its interface to the compiler and the compiler would use this for optimization (in a perfect world, the actual rewrite would then be checked using some sort of formal methods). I think that would be interesting, but we're very far from even being able to design something like that (at least in Base - experiments with external AbstractInterpreters in this direction are encouraged). This PR tries to come up with a reasonable middle ground, where the compiler gets some knowledge of the protocol hardcoded without having to know about the implementation details of the data structure. The basic ideas is that `Core` provides some magic generic functions that implementations can extend. Semantically, they are not special. They dispatch as usual, and implementations are expected to work properly even in the absence of any compiler optimizations. However, the compiler is semantically permitted to perform structural optimization using these magic generic functions. In the concrete case, this PR introduces the `KeyValue` interface which consists of two generic functions, `get` and `set`. The core optimization is that the compiler is allowed to rewrite any occurrence of `get(set(x, k, v), k)` into `v` without additional legality checks. In particular, the compiler performs no type checks, conversions, etc. The higher level implementation code is expected to do all that. This approach closely matches the general direction we've been taking in external AbstractInterpreters for embedding additional semantics and optimization opportunities into Julia code (although we generally use methods there, rather than full generic functions), so I think we have some evidence that this sort of approach works reasonably well. Nevertheless, this is certainly an experiment and the interface is explicitly declared unstable. ## Current Status This is fully working and implemented, but the optimization currently bails on anything but the simplest cases. Filling all those cases in is not particularly hard, but should be done along with a more invasive refactoring of SROA, so we should figure out the general direction here first and then we can finish all that up in a follow-up cleanup. ## Obligatory benchmark Before: ``` julia> using BenchmarkTools julia> function foo() a = Base.PersistentDict(:a => 1) return a[:a] end foo (generic function with 1 method) julia> @benchmark foo() BenchmarkTools.Trial: 10000 samples with 993 evaluations. Range (min … max): 32.940 ns … 28.754 μs ┊ GC (min … max): 0.00% … 99.76% Time (median): 49.647 ns ┊ GC (median): 0.00% Time (mean ± σ): 57.519 ns ± 333.275 ns ┊ GC (mean ± σ): 10.81% ± 2.22% ▃█▅ ▁▃▅▅▃▁ ▁▃▂ ▂ ▁▂▄▃▅▇███▇▃▁▂▁▁▁▁▁▁▁▁▂▂▅██████▅▂▁▁▁▁▁▁▁▁▁▁▂▃▃▇███▇▆███▆▄▃▃▂▂ ▃ 32.9 ns Histogram: frequency by time 68.6 ns < Memory estimate: 128 bytes, allocs estimate: 4. julia> @code_typed foo() CodeInfo( 1 ─ %1 = invoke Vector{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}}(Base.HashArrayMappedTries.undef::UndefInitializer, 1::Int64)::Vector{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}} │ %2 = %new(Base.HashArrayMappedTries.HAMT{Symbol, Int64}, %1, 0x00000000)::Base.HashArrayMappedTries.HAMT{Symbol, Int64} │ %3 = %new(Base.HashArrayMappedTries.Leaf{Symbol, Int64}, :a, 1)::Base.HashArrayMappedTries.Leaf{Symbol, Int64} │ %4 = Base.getfield(%2, :data)::Vector{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}} │ %5 = $(Expr(:boundscheck, true))::Bool └── goto #5 if not %5 2 ─ %7 = Base.sub_int(1, 1)::Int64 │ %8 = Base.bitcast(UInt64, %7)::UInt64 │ %9 = Base.getfield(%4, :size)::Tuple{Int64} │ %10 = $(Expr(:boundscheck, true))::Bool │ %11 = Base.getfield(%9, 1, %10)::Int64 │ %12 = Base.bitcast(UInt64, %11)::UInt64 │ %13 = Base.ult_int(%8, %12)::Bool └── goto #4 if not %13 3 ─ goto #5 4 ─ %16 = Core.tuple(1)::Tuple{Int64} │ invoke Base.throw_boundserror(%4::Vector{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}}, %16::Tuple{Int64})::Union{} └── unreachable 5 ┄ %19 = Base.getfield(%4, :ref)::MemoryRef{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}} │ %20 = Base.memoryref(%19, 1, false)::MemoryRef{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}} │ Base.memoryrefset!(%20, %3, :not_atomic, false)::MemoryRef{Union{Base.HashArrayMappedTries.HAMT{Symbol, Int64}, Base.HashArrayMappedTries.Leaf{Symbol, Int64}}} └── goto #6 6 ─ %23 = Base.getfield(%2, :bitmap)::UInt32 │ %24 = Base.or_int(%23, 0x00010000)::UInt32 │ Base.setfield!(%2, :bitmap, %24)::UInt32 └── goto #7 7 ─ %27 = %new(Base.PersistentDict{Symbol, Int64}, %2)::Base.PersistentDict{Symbol, Int64} └── goto #8 8 ─ %29 = invoke Base.getindex(%27::Base.PersistentDict{Symbol, Int64}, :a::Symbol)::Int64 └── return %29 ``` After: ``` julia> using BenchmarkTools julia> function foo() a = Base.PersistentDict(:a => 1) return a[:a] end foo (generic function with 1 method) julia> @benchmark foo() BenchmarkTools.Trial: 10000 samples with 1000 evaluations. Range (min … max): 2.459 ns … 11.320 ns ┊ GC (min … max): 0.00% … 0.00% Time (median): 2.460 ns ┊ GC (median): 0.00% Time (mean ± σ): 2.469 ns ± 0.183 ns ┊ GC (mean ± σ): 0.00% ± 0.00% ▂ █ ▁ █ ▂ █▁▁▁▁█▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁█▁▁▁▁█ █ 2.46 ns Histogram: log(frequency) by time 2.47 ns < Memory estimate: 0 bytes, allocs estimate: 0. julia> @code_typed foo() CodeInfo( 1 ─ return 1 ``` 27 November 2023, 17:01:53 UTC
9233a16 Jakob Nybo Nissen 27 November 2023, 06:01:45 UTC Document Base.StatStruct's fields as public (#50177) These fields are documented in the docstring of `stat`, and also mentioned as being public in the style guide, but their types are not documented, nor is `StatStruct` directly documented. --------- Co-authored-by: Jameson Nash <vtjnash@gmail.com> 27 November 2023, 06:01:45 UTC
9dcedaa Mason Protter 27 November 2023, 06:00:19 UTC Memoize `cwstring` when used for env lookup / modification on Windows (#51371) ~This is just me proposing a suggestion from @KristofferC in https://discourse.julialang.org/t/debug-has-massive-performance-impact/103974/22, it's all his code / idea, not mine.~ This PR makes it so that on windows, we pre-allocate an `IdDict` and every time someone looks up environment variables (motivating example here is `@debug` statements), we store the result of `cwstring(::String)` in that `IdDict` so that it doesn't need to be re-computed for future uses. The idea behind this is that people have observed that [using `@debug` is significantly more costly on Windows than other platforms](https://discourse.julialang.org/t/debug-has-massive-performance-impact/103974), even though we have documented in that manual that it should be a really cheap operation. @KristofferC suggests this is due to the fact that [checking environment variables in Windows is more costly](https://discourse.julialang.org/t/debug-has-massive-performance-impact/103974/18). ~The idea here is that we preallocate a `Cwstring` on Windows that just holds the text `"JULIA_DEBUG"`, so that if `access_env(f, "JULIA_DEBUG")` gets called, we don't need to create a new `Cwstring` and then throw it away each time.~ --------- Co-authored-by: Ian Butterworth <i.r.butterworth@gmail.com> Co-authored-by: Jameson Nash <vtjnash@gmail.com> 27 November 2023, 06:00:19 UTC
4a18886 Mosè Giordano 27 November 2023, 05:27:30 UTC More helpful error message for empty `cpu_target` in `Base.julia_cmd` (#52217) Fix #52209. 27 November 2023, 05:27:30 UTC
08d89eb Jameson Nash 27 November 2023, 04:27:43 UTC codegen: fix ssa order regression from initializing structs (#52311) 27 November 2023, 04:27:43 UTC
cd4f49a Keno Fischer 26 November 2023, 20:30:58 UTC Give a better assertion failure for module serialization issues (#52306) This issue confused me for a few hours. Basically what happened was that I had some IR that verified fine, but did not survive a deserialization round-trip (related to mismatching pointer types, which of course are starting to lose their meaning in LLVM). In this situation, the first assertion hit was the failure to verify the LLVM module at the output, but I had a hard time figuring out where this IR was coming from, since it looked totally corrupted. If LLVM assertions had been enabled, I would have seen the cantFail give a proper error, but since I only had Julia assertions enabled, I did not see this error message. Try to improve this situation by also asserting the absence of serialization errors using Julia assertions, not just LLVM assertions. 26 November 2023, 20:30:58 UTC
c30d45d Keno Fischer 26 November 2023, 16:05:52 UTC Make :enter a proper node type (#52300) This is a prepratory commit in anticipation of giving :enter additional responsibilities of entering and restoring dynamic scopes for ScopedValue (c.f. #51352). This commit simply turns `:enter` into its own node type (like the other terminators). The changes are largely mechanical from the `Expr` version, but will make it easier to add additional semantics in a follow up PR. 26 November 2023, 16:05:52 UTC
49c2d89 Jameson Nash 26 November 2023, 05:20:52 UTC jltypes: avoid creating lots of duplicates of this function (#52299) Core.Compiler calls this on many functions, creating associated Types inferred for each for some reason. This saves several MB from the system image. 26 November 2023, 05:20:52 UTC
9ea29d9 Valentin Churavy 25 November 2023, 15:13:27 UTC Make PersistentDict behave like an IdDict (#52193) 25 November 2023, 15:13:27 UTC
ea261ce Keno Fischer 25 November 2023, 14:16:02 UTC Automatically :leave the exception frame on the catch edge (#52245) Right now, we require a :leave expression at both the end of a try region and as the first expression in the catch block. This doesn't really make sense. Throwing the exception should leave the exception frame implicitly. This isn't a huge saving, but does save one IR node (and generated call in the native code) per try/catch block. 25 November 2023, 14:16:02 UTC
18c6c66 Keno Fischer 25 November 2023, 14:15:48 UTC Bail out of constprop if we already know it's gonna throw an error (#52293) While looking at some other things, I noticed that we call concrete evaluation on every `error("foo")`-like call just to find out again that it errors. which is obviously wasteful. In the future we may want to model exception-`:consistent`-cy in which case there could be some additional `exct` refinement here, but we're not there yet. --------- Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com> 25 November 2023, 14:15:48 UTC
cb01a3b Jameson Nash 25 November 2023, 04:45:22 UTC optimized (and ordered) IdSet code (#52114) We have had this smallintset code around for a while for internal purposes, though it was not quite fully general purpose (it didn't have pop). We also have around this tiny global_roots_table (about 1500 entries after building the sysig). This saves about 50% of the space for storing that table. It also optimizes all other IdSet code to not be an inefficient mutable wrapper around an IdDict, but instead be an ordered (by first insertion) set type of its own. 25 November 2023, 04:45:22 UTC
cc4424e Jishnu Bhattacharya 25 November 2023, 02:35:05 UTC Improve type-inference in complex eigen (#52290) Indexing using integers instead of a `Vector` uses constant-propagation to improve the inferred return types. After this, the return type of `eigen(::Matrix{ComplexF64})` is inferred as a small union. ```julia julia> @code_typed eigen(rand(ComplexF64,2,2)) CodeInfo( 1 ─ %1 = invoke LinearAlgebra.:(var"#eigen#94")(true::Bool, true::Bool, LinearAlgebra.eigsortby::typeof(LinearAlgebra.eigsortby), #self#::typeof(eigen), A::Matrix{ComplexF64})::Union{Eigen{ComplexF64, ComplexF64, Matrix{ComplexF64}, Vector{ComplexF64}}, Eigen{ComplexF64, Float64, Matrix{ComplexF64}, Vector{Float64}}} └── return %1 ) => Union{Eigen{ComplexF64, ComplexF64, Matrix{ComplexF64}, Vector{ComplexF64}}, Eigen{ComplexF64, Float64, Matrix{ComplexF64}, Vector{Float64}}} ``` Close #52289 25 November 2023, 02:35:05 UTC
da48487 Mason Protter 25 November 2023, 02:29:21 UTC Add assertion to `_sqrt_quasitriu_diag_block` (#52274) Fixes https://github.com/JuliaLang/julia/issues/52255 Before this change: ```julia julia> using JET julia> report_call(√, Tuple{Matrix{Complex{Float64}}}) ═════ 1 possible error found ═════ ┌ sqrt(A::Matrix{ComplexF64}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/dense.jl:884 │┌ sqrt(A::UpperTriangular{ComplexF64, Matrix{ComplexF64}}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2159 ││┌ sqrt_quasitriu(A0::UpperTriangular{ComplexF64, Matrix{ComplexF64}}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2184 │││┌ sqrt_quasitriu(A0::UpperTriangular{ComplexF64, Matrix{ComplexF64}}; blockwidth::Int64) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2211 ││││┌ kwcall(::@NamedTuple{blockwidth::Int64, n::Int64}, ::typeof(LinearAlgebra._sqrt_quasitriu!), R::Matrix{ComplexF64}, A::UpperTriangular{ComplexF64, Matrix{ComplexF64}}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2226 │││││┌ _sqrt_quasitriu!(R::Matrix{ComplexF64}, A::UpperTriangular{ComplexF64, Matrix{ComplexF64}}; blockwidth::Int64, n::Int64) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2228 ││││││┌ _sqrt_quasitriu_block!(R::Matrix{ComplexF64}, A::UpperTriangular{ComplexF64, Matrix{ComplexF64}}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2248 │││││││┌ _sqrt_quasitriu_diag_block!(R::Matrix{ComplexF64}, A::UpperTriangular{ComplexF64, Matrix{ComplexF64}}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2263 ││││││││┌ _sqrt_real_2x2!(R::SubArray{ComplexF64, 2, Matrix{ComplexF64}, Tuple{UnitRange{Int64}, UnitRange{Int64}}, false}, A::SubArray{ComplexF64, 2, UpperTriangular{ComplexF64, Matrix{ComplexF64}}, Tuple{UnitRange{Int64}, UnitRange{Int64}}, false}) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2311 │││││││││┌ _real_sqrt(θ::ComplexF64, μ::Float64) @ LinearAlgebra /home/mason/julia-dev/usr/share/julia/stdlib/v1.11/LinearAlgebra/src/triangular.jl:2323 ││││││││││┌ >=(x::ComplexF64, y::Int64) @ Base ./operators.jl:425 │││││││││││┌ <=(x::Int64, y::ComplexF64) @ Base ./operators.jl:401 ││││││││││││┌ <(x::Int64, y::ComplexF64) @ Base ./operators.jl:352 │││││││││││││ no matching method found `isless(::Int64, ::ComplexF64)`: isless(x::Int64, y::ComplexF64) ││││││││││││└──────────────────── ``` after this change ```julia julia> report_call(√, Tuple{Matrix{Complex{Float64}}}) No errors detected ``` There was a pre-existing comment in the function claiming "this branch is never reached when A is complex triangular". I don't fully understand why that would be the case, but if we believe it to be true, it would be good to share that information with the compiler. I used `@assert` here because it's believed by whoever wrote the algorithm that this branch is unreachable, so I think that's the correct way to use `@assert`, but if people have suggestions for a better way to communicate this info to the compiler, I'd gladly change things around. 25 November 2023, 02:29:21 UTC
3bdf9d5 Shuhei Kadowaki 25 November 2023, 02:26:01 UTC inference: optimize call to `builtin_tfunction` (#52284) By avoiding unnecessary copy of `argtypes[2:end]`. 25 November 2023, 02:26:01 UTC
c1fc985 Shuhei Kadowaki 25 November 2023, 02:23:33 UTC irinterp: improve semi-concrete interpretation accuracy (#52275) By enforcing re-inference on calls with all constant arguments. While it's debatable whether this approach is the most efficient, it was the easiest choice given that `used_ssas` based on `IncrementaCompact` wasn't an option for irinterp. - fixes #52202 - fixes #50037 25 November 2023, 02:23:33 UTC
93d4740 Jakob Nybo Nissen 25 November 2023, 01:11:40 UTC Document and export `Base.in!` (#51636) I think `in!` is a useful general function for users, and would be good to have as official API. Its semantics is clear and unambiguous, while providing a clear performance advantage over the naive implementation. For more evidence that this functionality is useful, consider: * Rust's `HashSet::insert` works just like this implementation of `in!` * This function was already used in the implementation of `Base.unique`, precisely for the performance over the naive approach Comes from #45156 with some initial discussion. 25 November 2023, 01:11:40 UTC
9c5def5 Leandro Martínez 25 November 2023, 01:05:06 UTC docs: simpler example for randn (#52252) As noted here: https://discourse.julialang.org/t/how-do-we-julians-win-big-when-the-situation-is-so-unfair/106433/63?u=lmiq The randn example is overly complicated and does not indicate the simplest usage, which is probably the most typical one. Co-authored-by: Steven G. Johnson <stevenj@mit.edu> 25 November 2023, 01:05:06 UTC
9e8fe68 Valentin Churavy 24 November 2023, 22:35:51 UTC Turn Method Overwritten Error into a PrecompileError -- turning off caching (#52214) Fixes #52213 Overwritting methods during cache creation is currently not something that the system can support and can lead to surprising, counter-intuitive and fatal errors. In 1.10 we turned it from a warning to a strong error, with this PR it remains a strong error, but the precompilation system recognizes it and essentially sets `__precompile__(false)` for this module and all modules that depend on it. Before: ``` julia> using OverwriteMethodError [ Info: Precompiling OverwriteMethodError [top-level] WARNING: Method definition +(Bool, Bool) in module Base at bool.jl:166 overwritten in module OverwriteMethodError at /home/vchuravy/src/julia2/OverwriteMethodError.jl:2. ERROR: LoadError: Method overwriting is not permitted during Module precompile. Stacktrace: [1] top-level scope @ ~/src/julia2/OverwriteMethodError.jl:2 [2] include @ Base ./Base.jl:489 [inlined] [3] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing) @ Base ./loading.jl:2216 [4] top-level scope @ stdin:3 in expression starting at /home/vchuravy/src/julia2/OverwriteMethodError.jl:1 in expression starting at stdin:3 ERROR: Failed to precompile OverwriteMethodError [top-level] to "/home/vchuravy/.julia/compiled/v1.10/jl_guiuCQ". Stacktrace: [1] error(s::String) @ Base ./error.jl:35 [2] compilecache(pkg::Base.PkgId, path::String, internal_stderr::IO, internal_stdout::IO, keep_loaded_modules::Bool) @ Base ./loading.jl:2462 [3] compilecache @ Base ./loading.jl:2334 [inlined] [4] (::Base.var"#968#969"{Base.PkgId})() @ Base ./loading.jl:1968 [5] mkpidlock(f::Base.var"#968#969"{Base.PkgId}, at::String, pid::Int32; kwopts::@Kwargs{stale_age::Int64, wait::Bool}) @ FileWatching.Pidfile ~/.julia/juliaup/julia-1.10.0-rc1+0.x64.linux.gnu/share/julia/stdlib/v1.10/FileWatching/src/pidfile.jl:93 [6] #mkpidlock#6 @ FileWatching.Pidfile ~/.julia/juliaup/julia-1.10.0-rc1+0.x64.linux.gnu/share/julia/stdlib/v1.10/FileWatching/src/pidfile.jl:88 [inlined] [7] trymkpidlock(::Function, ::Vararg{Any}; kwargs::@Kwargs{stale_age::Int64}) @ FileWatching.Pidfile ~/.julia/juliaup/julia-1.10.0-rc1+0.x64.linux.gnu/share/julia/stdlib/v1.10/FileWatching/src/pidfile.jl:111 [8] #invokelatest#2 @ Base ./essentials.jl:889 [inlined] [9] invokelatest @ Base ./essentials.jl:884 [inlined] [10] maybe_cachefile_lock(f::Base.var"#968#969"{Base.PkgId}, pkg::Base.PkgId, srcpath::String; stale_age::Int64) @ Base ./loading.jl:2977 [11] maybe_cachefile_lock @ Base ./loading.jl:2974 [inlined] [12] _require(pkg::Base.PkgId, env::String) @ Base ./loading.jl:1964 [13] __require_prelocked(uuidkey::Base.PkgId, env::String) @ Base ./loading.jl:1806 [14] #invoke_in_world#3 @ Base ./essentials.jl:921 [inlined] [15] invoke_in_world @ Base ./essentials.jl:918 [inlined] [16] _require_prelocked(uuidkey::Base.PkgId, env::String) @ Base ./loading.jl:1797 [17] macro expansion @ Base ./loading.jl:1784 [inlined] [18] macro expansion @ Base ./lock.jl:267 [inlined] [19] __require(into::Module, mod::Symbol) @ Base ./loading.jl:1747 [20] #invoke_in_world#3 @ Base ./essentials.jl:921 [inlined] [21] invoke_in_world @ Base ./essentials.jl:918 [inlined] [22] require(into::Module, mod::Symbol) @ Base ./loading.jl:1740 ``` After: ``` julia> using OverwriteMethodError ┌ Info: Precompiling OverwriteMethodError [top-level] └ @ Base loading.jl:2486 WARNING: Method definition +(Bool, Bool) in module Base at bool.jl:166 overwritten in module OverwriteMethodError at /home/vchuravy/src/julia2/OverwriteMethodError.jl:2. ERROR: Method overwriting is not permitted during Module precompile. ┌ Info: Skipping precompilation since __precompile__(false). Importing OverwriteMethodError [top-level]. └ @ Base loading.jl:2084 ``` --------- Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com> 24 November 2023, 22:35:51 UTC
6e23543 Keno Fischer 24 November 2023, 15:26:51 UTC Fix off-by-2 in codegen (#52292) This is cherry-picked from #52245. This is an independent bugfix, and looks like #52245 might need another round of discussion. There were two separate off-by-1's in the codegen code that is trying to detect assignments to slots inside try/catch regions. First, it was asking to include the value of the catch label, which is actually the first statement *not* in the try region. Second, there was a confusion of 0 and 1 based indexing in the iteration bounds. The end result of this was that the code was also looking at the first two statements of the catch region. This wasn't a problem before #52245 (other than a potentially over-conservative marking of some slots as volatile), because our catch blocks always had at least two statements (a :leave and a terminator), but with the `:leave` change, it is possible to have catch blocks with only one statement. If these happened to be at the end of the function, things would blow up. As a side node, this code isn't particularly sound, because it assumes that try/catch regions are lexical, which they are not. The assumption happens to work out ok for the code we generate in the frontend and optimized IR doesn't have slots, so we don't use this code, but it is not in general sound. 24 November 2023, 15:26:51 UTC
a386cd1 Gabriel Baraldi 24 November 2023, 13:51:32 UTC Fix multiversioning issues caused by the parallel llvm work (#52194) So after struggling with this for a long while it seems there were two different issues. The first one we lacked coverage over, but the other was a very subtle issue when we sorted the fptrs. ~I still need to add test that does multiversioning where we call between multiversioned functions~ Fixes https://github.com/JuliaLang/julia/issues/52079 24 November 2023, 13:51:32 UTC
187e8c2 Lilith Orion Hafner 23 November 2023, 21:16:52 UTC Add `BracketedSort` a new, faster algorithm for `partialsort` and friends (#52006) 23 November 2023, 21:16:52 UTC
79a845c Gabriel Baraldi 23 November 2023, 19:04:29 UTC Don't reuse passmanagers across compilations (#52054) 23 November 2023, 19:04:29 UTC
9884e44 Lilith Orion Hafner 23 November 2023, 16:16:15 UTC Don't print "No global of this name exists in this module." on UndefValError (#52280) 23 November 2023, 16:16:15 UTC
38438d7 Lilith Orion Hafner 23 November 2023, 16:15:22 UTC Remove upper bound in timer test (#52282) 23 November 2023, 16:15:22 UTC
0c46852 Shuhei Kadowaki 23 November 2023, 08:00:46 UTC effects: refine `:nothrow` when `exct` is known to be `Bottom` (#52270) Implements effects refinement that goes in the reverse direction of what was implemented in 8dd0cf5. In the discussion at JuliaLang/julia#52268, there's a debate on how to deal with exceptions like `StackOverflowError` or `InterruptException` that are caused by environment. The original purpose of #52268 was to fix issues where methods that could cause a `StackOverflowError` were mistakenly refined to `:nothrow`. But now it feels like it's a bit weird to model such environment-dependent exceptions as `:nothrow` in the first place. If we can exclude environment-dependent errors from the `:nothrow` modeling, those methods might be safely considered `:nothrow`. To prevent the concrete evaluation of methods that may cause `StackOverflowError`, it's enough to taint its `:teminates` after all. This commit excludes environment-depending errors from the `:nothrow` modeling, reverting the changes from #52268 while making it explicit in the `Effects` and `Base.@assume_effects` docstrings. Anyway, now the compile is able to prove `:nothrow`-ness of the following frame: ```julia function getindex_nothrow(xs::Vector{Int}, i::Int) try return xs[i] catch err err isa BoundsError && return nothing rethrow(err) end end ``` 23 November 2023, 08:00:46 UTC
a624d44 N5N3 23 November 2023, 07:22:28 UTC Widen diagonal var during `Type` unwrapping in `instanceof_tfunc` (#52228) close #52168 close #27031 23 November 2023, 07:22:28 UTC
10d58eb Shuhei Kadowaki 23 November 2023, 04:28:37 UTC reflection: add `Base.infer_return_type` utility (#52247) This commit introduces `Base.infer_return_type`, a new reflection utility which shares a similar interface with `Base.return_types` but differs in its output; `Base.infer_return_type` provides a singular return type taking into account all potential outcomes specified with the given call signature. This function parallels `Base.infer_effects` and the newly added `Base.infer_exception_type`, offering some utility, especially in testing scenarios. 23 November 2023, 04:28:37 UTC
44b8983 Shuhei Kadowaki 23 November 2023, 04:23:42 UTC compiler: add flag manipulation utilities (#52269) Right now, we're checking if a flag exists using bare operations like `&` and `==`. This works fine, but I think unifying these interfaces could make our code easier to maintain. So, this commit introduces some new high-level operators and refactored the code to incorporate them: - `has_flag(curr::UInt32, flag::UInt32)` - `has_flag(inst::Instruction, flag::UInt32)` - `add_flag!(inst::Instruction, flag::UInt32)` - `sub_flag!(inst::Instruction, flag::UInt32)` 23 November 2023, 04:23:42 UTC
418423b Christopher Burns 22 November 2023, 22:46:49 UTC optimize `allunique()` for sorted collections (#50372) 22 November 2023, 22:46:49 UTC
abfc2c6 Lilith Orion Hafner 22 November 2023, 18:54:09 UTC Add SubArray optimization to sorting (#52072) 22 November 2023, 18:54:09 UTC
05f4b05 Steven G. Johnson 22 November 2023, 16:23:07 UTC fix Unicode.julia_chartransform for Julia 1.10 (#52027) #49559 by @JeffBezanson updated `src/flisp/julia_charmap.h` but missed [the comment](https://github.com/JuliaLang/julia/blob/164969f3d06919b073f3aa9ee608e40974ca82d9/src/flisp/julia_charmap.h#L5-L6) noting that `base/strings/unicode.jl` has to be updated accordingly. 22 November 2023, 16:23:07 UTC
85e3da0 Diogo Netto 22 November 2023, 14:26:21 UTC add a compile-time option to enable 4k page sizes (#52229) We're suffering from heavy fragmentation in some of our workloads. Add a build-time option to enable 4k pages (instead of 16k) in the GC, since that improves memory utilization considerably for us. Drawback is that this may increase the number of `madvise` system calls in the sweeping phase by a factor of 4, but concurrent page sweeping should help with some of that. 22 November 2023, 14:26:21 UTC
8c9ac8d Jishnu Bhattacharya 22 November 2023, 13:49:31 UTC Declare `LinearAlgebra.AbstractTriangular` to be public (#52246) Since methods such as `mul!`, `(l/r)mul!` and `(l/r)div!` are defined for `AbstractTriangular`, having this be public allows easier disambiguation in packages. [Several packages](https://juliahub.com/ui/Search?q=AbstractTriangular&type=code) are already using it as if it's public, so it makes sense to support this. This would resolve the specific issue in https://discourse.julialang.org/t/methoderrors-suggest-fixes-that-may-depend-on-internal-bindings/106468 22 November 2023, 13:49:31 UTC
1b40e91 Viral B. Shah 22 November 2023, 09:01:42 UTC Fix #52216 (#52266) 22 November 2023, 09:01:42 UTC
a0a2bda Shuhei Kadowaki 22 November 2023, 09:00:29 UTC inference: incorporate stackoverflow possibility into exc type modeling (#52268) Currently `exc_bestguess` does not take into account the possibility of stackoverflow error, causing the inconsistency between exception type modeling and `:nothrow` modeling. This commit fixes it up. 22 November 2023, 09:00:29 UTC
49d3e85 Shuhei Kadowaki 22 November 2023, 08:40:32 UTC inference: update `exc_bestguess` when seeing unsafe `GotoIfNot` (#52267) 22 November 2023, 08:40:32 UTC
a6c656e Gabriel Baraldi 21 November 2023, 21:06:36 UTC Make have_fma consistent between interpreter and compiled (#52206) Currently the interpreter always returns false. Which isn't very good. Make it follow whatever the JIT will do. 21 November 2023, 21:06:36 UTC
0402c78 Shuhei Kadowaki 21 November 2023, 11:58:25 UTC inference: followups for #51754 (#52241) Composed of: - typeinf_local: factor into `update_cycle_worklists!` utility (78f7b4ecf11b364e543bdfd46aa5fc49b7bdbf42) - inference: fix exception type of `typename` call (fac36d839cb545a1a12991596aafd5584f95bf3b) - add missing type annotations (7ce140ea782c847c2c2253a65301d295b10aa183) - inference: refine exct information if `:nothrow` is proven (76143d37b6563d2da4203747051ef8517453db0d) - ~~improve exception type inference for core math functions (525bd6c2538cbfebc9432df53b0005c9956079be)~~ Separated into another PR 21 November 2023, 11:58:25 UTC
527af66 Shuhei Kadowaki 21 November 2023, 11:55:13 UTC inference: add reflection utility for exception type analysis (#52240) This commit defines functions that mirror our tools for analyzing return types and computational effects. The key point to discuss is that this commit introduces two functions: `Base.infer_exception_types` and `Base.infer_exception_type`. `Base.infer_exception_types` acts like `Base.return_types`, giving a list of exception types for each method that matches with the given call signature. On the other hand, `Base.infer_exception_type` is akin to `Base.infer_effects`, returning a single exception type that covers all potential outcomes entailed by the given call signature. I personally lean towards the latter for its utility, particularly in testing scenarios, but I included `infer_exception_types` too for consistency with `return_types`. I'd welcome any feedback on this approach. 21 November 2023, 11:55:13 UTC
8dd0cf5 Shuhei Kadowaki 20 November 2023, 09:19:27 UTC inference: refine `exct` information if `:nothrow` is proven 21 November 2023, 09:53:19 UTC
d85cb0e Shuhei Kadowaki 20 November 2023, 09:17:28 UTC add missing type annotations 21 November 2023, 09:51:17 UTC
808d7ac Shuhei Kadowaki 20 November 2023, 09:17:13 UTC inference: fix exception type of `typename` call 21 November 2023, 09:51:17 UTC
da1258c Shuhei Kadowaki 20 November 2023, 09:16:44 UTC `typeinf_local`: factor into `update_cycle_worklists!` utility 21 November 2023, 09:51:17 UTC
15ab026 Shuhei Kadowaki 20 November 2023, 17:59:58 UTC inference: add reflection utility for exception type analysis This commit defines functions that mirror our tools for analyzing return types and computational effects. The key point to discuss is that this commit introduces two functions: `Base.exception_types` and `Base.exception_type`. `Base.exception_types` acts like `Base.return_types`, giving a list of exception types for each method that matches with the given call signature. On the other hand, `Base.exception_type` is akin to `Base.infer_effects`, returning a single exception type that covers all potential outcomes entailed by the given call signature. I personally lean towards the latter for its utility, particularly in testing scenarios, but I included `exception_types` too for consistency with `return_types`. I'd welcome any feedback on this approach. 21 November 2023, 09:15:27 UTC
65090d1 Kristoffer Carlsson 21 November 2023, 02:08:45 UTC tweak the error printed for `PrecompileError` to indicate that it doesn't have to be due to `__precompile__(false)` (#51367) 21 November 2023, 02:08:45 UTC
67161a3 Mosè Giordano 20 November 2023, 17:10:15 UTC Silence noisy test in `test/cmdlineargs.jl` (#52225) This is spamming ([example](https://buildkite.com/julialang/julia-master/builds/30247#018be235-0cd3-43bb-ba43-cc378ac0d682/792-1056)) ``` From worker 12: ERROR: LoadError: UndefVarError: `@which` not defined in `Main` From worker 12: Stacktrace: From worker 12: [1] top-level scope From worker 12: @ :0 From worker 12: [2] lower From worker 12: @ ./meta.jl:163 [inlined] From worker 12: [3] eval_user_input(errio::IOContext{Base.PipeEndpoint}, ast::Any, show_value::Bool) From worker 12: @ Base ./client.jl:141 From worker 12: [4] run_main_repl(interactive::Bool, quiet::Bool, banner::Symbol, history_file::Bool, color_set::Bool) From worker 12: @ Base ./client.jl:477 From worker 12: [5] repl_main From worker 12: @ Base ./client.jl:561 [inlined] From worker 12: [6] _start() From worker 12: @ Base ./client.jl:535 From worker 12: in expression starting at none:1 ``` in all jobs 20 November 2023, 17:10:15 UTC
5cb0e51 Tim Besard 20 November 2023, 15:45:21 UTC build: ASAN fixes for glibc (#51755) For the `sigsetjmp` bypass; looks like glibc removed the `__libc_siglongjmp` symbol in glibc 2.34, so change to using the approach taking by our `dlopen` wrapper instead. Adopts topolarity's fixes from #50170 Resolves #47698 Co-authored-by: Jameson Nash <vtjnash@gmail.com> 20 November 2023, 15:45:21 UTC
7327a8f Shuhei Kadowaki 20 November 2023, 13:23:39 UTC effects: add some more test cases for `Base.@propagate_inbounds` (#52236) 20 November 2023, 13:23:39 UTC
72cd63c Jameson Nash 20 November 2023, 03:03:15 UTC jitlayers: reduce excess alignment of #52182 (#52210) 20 November 2023, 03:03:15 UTC
c8ca350 Keno Fischer 19 November 2023, 22:11:17 UTC inference: Model type propagation through exceptions (#51754) Currently the type of a caught exception is always modeled as `Any`. This isn't a huge problem, because control flow in Julia is generally assumed to be somewhat slow, so the extra type imprecision of not knowing the return type does not matter all that much. However, there are a few situations where it matters. For example: ``` maybe_getindex(A, i) = try; A[i]; catch e; isa(e, BoundsError) && return nothing; rethrow(); end ``` At present, we cannot infer :nothrow for this method, even if that is the only error type that `A[i]` can throw. This is particularly noticable, since we can now optimize away `:nothrow` exception frames entirely (#51674). Note that this PR still does not make the above example particularly efficient (at least interprocedurally), though specialized codegen could be added on top of this to make that happen. It does however improve the inference result. A second major motivation of this change is that reasoning about exception types is likely to be a major aspect of any future work on interface checking (since interfaces imply the absence of MethodErrors), so this PR lays the groundwork for appropriate modeling of these error paths. Note that this PR adds all the required plumbing, but does not yet have a particularly precise model of error types for our builtins, bailing to `Any` for any builtin not known to be `:nothrow`. This can be improved in follow up PRs as required. 19 November 2023, 22:11:17 UTC
f5d189f Shuhei Kadowaki 19 November 2023, 15:50:33 UTC effects: don't taint `:noub` for `:new` allocations (#52222) After #52169, the UB previously associated with allocations with uninitialized fields has been addressed, so there's no longer a need to taint `:noub` for `:new` allocations during abstract interpretation. I believe, even without #52169, uninitialized field does not inherently leads to UB, but just causes inconsistency of the program, since what actually causes UB is `getfield` that accesses into whatever object, but not the allocation itself. 19 November 2023, 15:50:33 UTC
c07893d Jishnu Bhattacharya 19 November 2023, 10:09:19 UTC Cartesian indexing for SubArrays with non-integer AbstractRanges (#52094) With #50457 now merged, an `AbstractRange` of `CartesianIndex`es should use `CartesianIndexing` in constructing a `SubArray`. I've limited the method to integer ranges, as this is the case where we know for sure that the indexing may be linear. Fixes ```julia julia> view(1:2, StepRangeLen(CartesianIndex(1), CartesianIndex(1), 0)) 0-element view(::UnitRange{Int64}, StepRangeLen(CartesianIndex(1,), CartesianIndex(1,), 0)) with eltype Int64 ``` --------- Co-authored-by: N5N3 <2642243996@qq.com> 19 November 2023, 10:09:19 UTC
ec3911c Daniel Karrasch 19 November 2023, 08:36:43 UTC Add `lmul!` and `rmul!` for `Bidiagonal` (#51777) 19 November 2023, 08:36:43 UTC
back to top