Skip to content

faster for now#2

Closed
adienes wants to merge 5 commits intomasterfrom
faster_reinterpretarray
Closed

faster for now#2
adienes wants to merge 5 commits intomasterfrom
faster_reinterpretarray

Conversation

@adienes
Copy link
Copy Markdown
Owner

@adienes adienes commented Aug 15, 2025

No description provided.

BioTurboNick and others added 5 commits August 14, 2025 02:46
Fixes JuliaLang#59223 by adding intermediary function names to use the same
`__repl_entry` prefix.
…cter, fixup docstring for `joinpath` (JuliaLang#58951)

Fixes JuliaLang#58929

Only a single letter followed by a colon is a valid drive prefix for
this format, any other length of string prior to a colon isn't a valid
drive in Windows:
https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats

Also the docstring for `joinpath` rendered Windows paths as unescaped,
meaning they could not be copied and pasted on the REPL.
@adienes adienes closed this Aug 15, 2025
@adienes adienes deleted the faster_reinterpretarray branch August 15, 2025 14:29
adienes added a commit that referenced this pull request Sep 12, 2025
… of `ReshapedArray` (JuliaLang#43518)

This performance difference was found when working on JuliaLang#42736.
Currently, our `ReshapedArray` use stride based `MultiplicativeInverse`
to speed up index transformation.
For example, for `a::AbstractArray{T,3}` and `b = vec(a)`, the index
transformation is equivalent to:
```julia
offset = i - 1                        # b[i]
d1, r1 = divrem(offset, stride(a, 3)) # stride(a, 3) = size(a, 1) * size(a, 2)
d2, r2 = divrem(r1, stride(a, 2))     # stride(a, 2) = size(a, 1)
CartesianIndex(r2 + 1, d2 +1, d1 + 1) # a has one-based axes
```
(All the `stride` is replaced with a `MultiplicativeInverse` to
accelerate `divrem`)

This PR wants to replace the above machinery with:
```julia
offset = i - 1               
d1, r1 = divrem(offset, size(a, 1))
d2, r2 = divrem(d1, size(a, 2))
CartesianIndex(r1 + 1, r2 +1, d2 + 1)
```
For random access, they should have the same computational cost. But for
sequential access, like `sum(b)`, `size` based transformation seems
faster.
To avoid bottleneck from IO, use `reshape(::CartesianIndices, x...)` to
benchmark:
```julia
f(x) = let r = 0
           for i in eachindex(x)
               @inbounds r |= +(x[i].I...)
           end
           r
       end
a = CartesianIndices((99,100,101));
@Btime f(vec($a));                 #2.766 ms  -->  2.591 ms
@Btime f(reshape($a,990,1010));    #3.412 ms  -->  2.626 ms
@Btime f(reshape($a,33,300,101));  #3.422 ms  -->  2.342 ms
```
I haven't looked into the reason for this performance difference.

Beside acceleration, this also makes it possible to reuse the
`MultiplicativeInverse` in some cases (like JuliaLang#42736).
So I think it might be useful?

---------

Co-authored-by: Andy Dienes <51664769+adienes@users.noreply.github.com>
Co-authored-by: Andy Dienes <andydienes@gmail.com>
adienes pushed a commit that referenced this pull request Sep 15, 2025
Fixes
https://buildkite.com/julialang/julia-master/builds/46446#0195f712-1844-4e81-8b16-27b953fedcd3/899-1778

```
  | Error in testset Profile:
  | Test Failed at /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/stdlib/v1.13/Profile/test/runtests.jl:231
  | Expression: occursin("@Compiler" * slash, str)
  | Evaluated: occursin("@Compiler/", "Overhead ╎ [+additional indent] Count File:Line  Function\n=========================================================\n   ╎9   @juliasrc/task.c:1249  start_task\n   ╎ 9   @juliasrc/julia.h:2353  jl_apply\n   ╎  9   @juliasrc/gf.c:3693  ijl_apply_generic\n   ╎   9   @juliasrc/gf.c:3493  _jl_invoke\n   ╎    9   [unknown stackframe]\n   ╎     9   @Distributed/src/process_messages.jl:287  (::Distributed.var\"#handle_msg##2#handle_msg##3\"{Distributed.CallMsg{:call_fetch}, Distributed.MsgHeader, Sockets.TCPSocket})()\n   ╎    ╎ 9   @Distributed/src/process_messages.jl:70  run_work_thunk(thunk::Distributed.var\"#handle_msg##4#handle_msg##5\"{Distributed.CallMsg{:call_fetch}}, print_error::Bool)\n   ╎    ╎  9   @Distributed/src/process_messages.jl:287  (::Distributed.var\"#handle_msg##4#handle_msg##5\"{Distributed.CallMsg{:call_fetch}})()\n   ╎    ╎   9   @juliasrc/builtins.c:841  jl_f__apply_iterate\n   ╎    ╎    9   @juliasrc/julia.h:2353  jl_apply\n   ╎    ╎     9   @juliasrc/gf.c:3693  ijl_apply_generic\n   ╎    ╎    ╎ 9   @juliasrc/gf.c:3493  _jl_invoke\n   ╎    ╎    ╎  9   @Base/Base_compiler.jl:223  kwcall(::@NamedTuple{seed::UInt128}, ::typeof(invokelatest), ::Function, ::String, ::Vararg{String})\n   ╎    ╎    ╎   9   @juliasrc/builtins.c:841  jl_f__apply_iterate\n   ╎    ╎    ╎    9   @juliasrc/julia.h:2353  jl_apply\n   ╎    ╎    ╎     9   @juliasrc/gf.c:3693  ijl_apply_generic\n   ╎    ╎    ╎    ╎ 9   @juliasrc/gf.c:3493  _jl_invoke\n   ╎    ╎    ╎    ╎  9   @juliasrc/builtins.c:853  jl_f_invokelatest\n   ╎    ╎    ╎    ╎   9   @juliasrc/julia.h:2353  jl_apply\n   ╎    ╎    ╎    ╎    9   @juliasrc/gf.c:3693  ijl_apply_generic\n   ╎    ╎    ╎    ╎     9   @juliasrc/gf.c:3493  _jl_invoke\n   ╎    ╎    ╎    ╎    ╎ 9   [unknown stackframe]\n   ╎    ╎    ╎    ╎    ╎  9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:7  kwcall(::@NamedTuple{seed::UInt128}, ::typeof(runtests), name::String, path::String)\n   ╎    ╎    ╎    ╎    ╎   9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:7  runtests\n   ╎    ╎    ╎    ╎    ╎    9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:13  runtests(name::String, path::String, isolate::Bool; seed::UInt128)\n   ╎    ╎    ╎    ╎    ╎     9   @Base/env.jl:265  withenv(f::var\"#4#5\"{UInt128, String, String, Bool, Bool}, keyvals::Pair{String, Bool})\n   ╎    ╎    ╎    ╎    ╎    ╎ 9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:27  (::var\"#4#5\"{UInt128, String, String, Bool, Bool})()\n   ╎    ╎    ╎    ╎    ╎    ╎  9   @Base/timing.jl:621  macro expansion\n   ╎    ╎    ╎    ╎    ╎    ╎   9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:29  macro expansion\n   ╎    ╎    ╎    ╎    ╎    ╎    9   @Test/src/Test.jl:1835  macro expansion\n   ╎    ╎    ╎    ╎    ╎    ╎     9   /cache/build/tester-amdci5-10/julialang/julia-master/julia-7c9af464cc/share/julia/test/testdefs.jl:37  macro expansion\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎ 9   @Base/Base.jl:303  include(mod::Module, _path::String)\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎  9   @Base/loading.jl:2925  _include(mapexpr::Function, mod::Module, _path::String)\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎   9   @juliasrc/gf.c:3693  ijl_apply_generic\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    9   @juliasrc/gf.c:3493  _jl_invoke\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎     9   @Base/loading.jl:2865  include_string(mapexpr::typeof(identity), mod::Module, code::String, filename::String)\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎ 9   @Base/boot.jl:489  eval(m::Module, e::Any)\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎  9   @juliasrc/toplevel.c:1095  ijl_toplevel_eval_in\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎   9   @juliasrc/toplevel.c:1050  ijl_toplevel_eval\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    9   @juliasrc/toplevel.c:978  jl_toplevel_eval_flex\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎     9   @juliasrc/toplevel.c:1038  jl_toplevel_eval_flex\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎ 9   @juliasrc/interpreter.c:897  jl_interpret_toplevel_thunk\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎  9   @juliasrc/interpreter.c:557  eval_body\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎   9   @juliasrc/interpreter.c:557  eval_body\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    9   @juliasrc/interpreter.c:557  eval_body\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎     9   @juliasrc/interpreter.c:692  eval_body\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎ 9   @juliasrc/interpreter.c:193  eval_stmt_value\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎  9   @juliasrc/interpreter.c:242  eval_value\n   ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎    ╎   9   @juliasrc/interpreter.c:124  do_call\n   ╎    ╎    ╎    ╎
...
```
adienes pushed a commit that referenced this pull request Sep 15, 2025
Use an atomic fetch and add to fix a data race in `Module()` identified
by tsan:

```
./usr/bin/julia -t4,0 --gcthreads=1 -e 'Threads.@threads for i=1:100 Module() end'
==================
WARNING: ThreadSanitizer: data race (pid=5575)
  Write of size 4 at 0xffff9bf9bd28 by thread T9:
    #0 jl_new_module__ /home/user/c/julia/src/module.c:487:22 (libjulia-internal.so.1.13+0x897d4)
    #1 jl_new_module_ /home/user/c/julia/src/module.c:527:22 (libjulia-internal.so.1.13+0x897d4)
    #2 jl_f_new_module /home/user/c/julia/src/module.c:649:22 (libjulia-internal.so.1.13+0x8a968)
    #3 <null> <null> (0xffff76a21164)
    #4 <null> <null> (0xffff76a1f074)
    #5 <null> <null> (0xffff76a1f0c4)
    #6 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5ea04)
    #7 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5ea04)
    #8 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0x9e4c4)
    #9 start_task /home/user/c/julia/src/task.c:1249:19 (libjulia-internal.so.1.13+0x9e4c4)

  Previous write of size 4 at 0xffff9bf9bd28 by thread T10:
    #0 jl_new_module__ /home/user/c/julia/src/module.c:487:22 (libjulia-internal.so.1.13+0x897d4)
    #1 jl_new_module_ /home/user/c/julia/src/module.c:527:22 (libjulia-internal.so.1.13+0x897d4)
    #2 jl_f_new_module /home/user/c/julia/src/module.c:649:22 (libjulia-internal.so.1.13+0x8a968)
    #3 <null> <null> (0xffff76a21164)
    #4 <null> <null> (0xffff76a1f074)
    #5 <null> <null> (0xffff76a1f0c4)
    #6 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5ea04)
    #7 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5ea04)
    #8 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0x9e4c4)
    #9 start_task /home/user/c/julia/src/task.c:1249:19 (libjulia-internal.so.1.13+0x9e4c4)

  Location is global 'jl_new_module__.mcounter' of size 4 at 0xffff9bf9bd28 (libjulia-internal.so.1.13+0x3dbd28)
```
adienes pushed a commit that referenced this pull request Sep 15, 2025
…aLang#58893)

When invoking any "functor-like", such as a closure:
```julia
bar(x) = @noinline ((y)->x+y)(x)
```
our IR printing was not showing the arg0 invoked, even when it is
required to determine which MethodInstance this is invoking.

Before:
```julia
julia> @code_typed optimize=true bar(1)
CodeInfo(
1 ─ %1 = %new(var"#bar##2#bar##3"{Int64}, x)::var"#bar##2#bar##3"{Int64}
│   %2 =    invoke %1(x::Int64)::Int64
└──      return %2
) => Int64
```

After:
```julia
julia> @code_typed optimize=true bar(1)
CodeInfo(
1 ─ %1 = %new(var"#bar##2#bar##3"{Int64}, x)::var"#bar##2#bar##3"{Int64}
│   %2 =    invoke (%1::var"#bar##2#bar##3"{Int64})(x::Int64)::Int64
└──      return %2
) => Int64
```
adienes pushed a commit that referenced this pull request Sep 15, 2025
Simplify `workqueue_for`. While not strictly necessary, the acquire load
in `getindex(once::OncePerThread{T,F}, tid::Integer)` makes
ThreadSanitizer happy. With the existing implementation, we get false
positives whenever a thread other than the one that originally allocated
the array reads it:

```
==================
WARNING: ThreadSanitizer: data race (pid=6819)
  Atomic read of size 8 at 0xffff86bec058 by main thread:
    #0 getproperty Base_compiler.jl:57 (sys.so+0x113b478)
    #1 julia_pushNOT._1925 task.jl:868 (sys.so+0x113b478)
    #2 julia_enq_work_1896 task.jl:969 (sys.so+0x5cd218)
    #3 schedule task.jl:983 (sys.so+0x892294)
    #4 macro expansion threadingconstructs.jl:522 (sys.so+0x892294)
    #5 julia_start_profile_listener_60681 Base.jl:355 (sys.so+0x892294)
    #6 julia___init___60641 Base.jl:392 (sys.so+0x1178dc)
    #7 jfptr___init___60642 <null> (sys.so+0x118134)
    #8 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5e9a4)
    #9 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5e9a4)
    #10 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0xbba74)
    #11 jl_module_run_initializer /home/user/c/julia/src/toplevel.c:68:13 (libjulia-internal.so.1.13+0xbba74)
    JuliaLang#12 _finish_jl_init_ /home/user/c/julia/src/init.c:632:13 (libjulia-internal.so.1.13+0x9c0fc)
    JuliaLang#13 ijl_init_ /home/user/c/julia/src/init.c:783:5 (libjulia-internal.so.1.13+0x9bcf4)
    JuliaLang#14 jl_repl_entrypoint /home/user/c/julia/src/jlapi.c:1125:5 (libjulia-internal.so.1.13+0xf7ec8)
    JuliaLang#15 jl_load_repl /home/user/c/julia/cli/loader_lib.c:601:12 (libjulia.so.1.13+0x11934)
    JuliaLang#16 main /home/user/c/julia/cli/loader_exe.c:58:15 (julia+0x10dc20)

  Previous write of size 8 at 0xffff86bec058 by thread T2:
    #0 IntrusiveLinkedListSynchronized task.jl:863 (sys.so+0x78d220)
    #1 macro expansion task.jl:932 (sys.so+0x78d220)
    #2 macro expansion lock.jl:376 (sys.so+0x78d220)
    #3 julia_workqueue_for_1933 task.jl:924 (sys.so+0x78d220)
    #4 julia_wait_2048 task.jl:1204 (sys.so+0x6255ac)
    #5 julia_task_done_hook_49205 task.jl:839 (sys.so+0x128fdc0)
    #6 jfptr_task_done_hook_49206 <null> (sys.so+0x902218)
    #7 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5e9a4)
    #8 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5e9a4)
    #9 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0x9c79c)
    #10 jl_finish_task /home/user/c/julia/src/task.c:345:13 (libjulia-internal.so.1.13+0x9c79c)
    #11 jl_threadfun /home/user/c/julia/src/scheduler.c:122:5 (libjulia-internal.so.1.13+0xe7db8)

  Thread T2 (tid=6824, running) created by main thread at:
    #0 pthread_create <null> (julia+0x85f88)
    #1 uv_thread_create_ex /workspace/srcdir/libuv/src/unix/thread.c:172 (libjulia-internal.so.1.13+0x1a8d70)
    #2 _finish_jl_init_ /home/user/c/julia/src/init.c:618:5 (libjulia-internal.so.1.13+0x9c010)
    #3 ijl_init_ /home/user/c/julia/src/init.c:783:5 (libjulia-internal.so.1.13+0x9bcf4)
    #4 jl_repl_entrypoint /home/user/c/julia/src/jlapi.c:1125:5 (libjulia-internal.so.1.13+0xf7ec8)
    #5 jl_load_repl /home/user/c/julia/cli/loader_lib.c:601:12 (libjulia.so.1.13+0x11934)
    #6 main /home/user/c/julia/cli/loader_exe.c:58:15 (julia+0x10dc20)

SUMMARY: ThreadSanitizer: data race Base_compiler.jl:57 in getproperty
==================
```
adienes pushed a commit that referenced this pull request Oct 10, 2025
Use an atomic fetch and add to fix a data race in `Module()` identified
by tsan:

```
./usr/bin/julia -t4,0 --gcthreads=1 -e 'Threads.@threads for i=1:100 Module() end'
==================
WARNING: ThreadSanitizer: data race (pid=5575)
  Write of size 4 at 0xffff9bf9bd28 by thread T9:
    #0 jl_new_module__ /home/user/c/julia/src/module.c:487:22 (libjulia-internal.so.1.13+0x897d4)
    #1 jl_new_module_ /home/user/c/julia/src/module.c:527:22 (libjulia-internal.so.1.13+0x897d4)
    #2 jl_f_new_module /home/user/c/julia/src/module.c:649:22 (libjulia-internal.so.1.13+0x8a968)
    #3 <null> <null> (0xffff76a21164)
    #4 <null> <null> (0xffff76a1f074)
    #5 <null> <null> (0xffff76a1f0c4)
    #6 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5ea04)
    #7 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5ea04)
    #8 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0x9e4c4)
    #9 start_task /home/user/c/julia/src/task.c:1249:19 (libjulia-internal.so.1.13+0x9e4c4)

  Previous write of size 4 at 0xffff9bf9bd28 by thread T10:
    #0 jl_new_module__ /home/user/c/julia/src/module.c:487:22 (libjulia-internal.so.1.13+0x897d4)
    #1 jl_new_module_ /home/user/c/julia/src/module.c:527:22 (libjulia-internal.so.1.13+0x897d4)
    #2 jl_f_new_module /home/user/c/julia/src/module.c:649:22 (libjulia-internal.so.1.13+0x8a968)
    #3 <null> <null> (0xffff76a21164)
    #4 <null> <null> (0xffff76a1f074)
    #5 <null> <null> (0xffff76a1f0c4)
    #6 _jl_invoke /home/user/c/julia/src/gf.c (libjulia-internal.so.1.13+0x5ea04)
    #7 ijl_apply_generic /home/user/c/julia/src/gf.c:3892:12 (libjulia-internal.so.1.13+0x5ea04)
    #8 jl_apply /home/user/c/julia/src/julia.h:2343:12 (libjulia-internal.so.1.13+0x9e4c4)
    #9 start_task /home/user/c/julia/src/task.c:1249:19 (libjulia-internal.so.1.13+0x9e4c4)

  Location is global 'jl_new_module__.mcounter' of size 4 at 0xffff9bf9bd28 (libjulia-internal.so.1.13+0x3dbd28)
```

(cherry picked from commit 9039555)
adienes pushed a commit that referenced this pull request Jan 29, 2026
…60804)

We were missing handling for the case where the binding that we're using
is ambiguous. There are two possible behaviors:

1. The ambiguous binding gets ignored for the purpose of resolution
2. The ambiguity poisons and the imported binding is also ambiguous

Current behavior between these two depends on resolution order (which is
bad and part of what the assert was complaining about). This decides
that case #2 is the correct behavior and fixes JuliaLang#60659.
adienes pushed a commit that referenced this pull request Mar 19, 2026
`@nospecialize` and `@specialize` refer to names passed as macro
arguments, so
should theoretically escape them in their expansion. They currently work
without escaping because macroexpand.scm makes a special case for
`:meta` forms.
Unfortunately, that special handling escapes `:meta` too aggressively:

```
julia> macro mac(x); x; end
@mac (macro with 1 method)

julia> ex = @macroexpand @mac function f(@nospecialize(a))
                  a
              end
:(function Main.f($(Expr(:meta, :nospecialize, :a)))
      #= REPL[2]:1 =#
      #= REPL[2]:2 =#
      var"#2#a"
  end)

julia> func = @mac function f(@nospecialize(a))
                  a
              end
f (generic function with 1 method)

julia> func(1)
ERROR: UndefVarError: `#3#a` not defined in `Main`
```

This PR doesn't fix the above or change any current behaviour, but at
least
ensures that JuliaLowering doesn't need to introduce the same bug. There
are
alternatives if this doesn't work, but all would be hacky.
adienes pushed a commit that referenced this pull request Mar 27, 2026
…#61330)

Should prevent these invalidations seen when loading CurveFit.jl on
1.13:
```julia
inserting merge!(m::DataStructures.SortedDict{K, D, Ord}, others::AbstractDict{K, D}...) where {K, D, Ord<:Ordering} @ DataStructures ~/.julia/packages/DataStructures/qUuAY/src/sorted_dict.jl:473 invalidated:
   mt_backedges: 1: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator{_A, Base.Compiler.IRShow.var"JuliaLang#30#31"} where _A, ::Any) where {K, V} (0 children)
                 2: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator, ::Any) where {K, V} (0 children)
                 3: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator, ::Any) where {K, V} (0 children)
                 4: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator{I, Base.var"#Generator##0#Generator##1"{NonlinearSolveBase.Utils.var"#norm_op##2#norm_op##3"{typeof(+)}}} where I<:(Base.Iterators.Zip{Is} where Is<:Tuple{Base.AbstractBroadcasted, Base.AbstractBroadcasted}), ::Tuple{Tuple{Any, Any}, Tuple{Any, Any}}) where {K, V} (0 children)
                 5: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator{_A, F} where {_A, F<:DifferentiationInterface.var"#_prepare_jacobian_aux##0#_prepare_jacobian_aux##1"}, ::Any) where {K, V} (0 children)
                 6: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator{_A, F} where {_A, F<:DifferentiationInterface.var"#_prepare_jacobian_aux#JuliaLang#12#_prepare_jacobian_aux#JuliaLang#13"}, ::Any) where {K, V} (0 children)
                 7: signature Tuple{typeof(merge!), Any, AbstractDict} triggered MethodInstance for Base.grow_to!(::AbstractDict{K, V}, ::Base.Generator{I, Base.var"#Generator##0#Generator##1"{NonlinearSolveBase.Utils.var"#norm_op##2#norm_op##3"{typeof(+)}}} where I<:(Base.Iterators.Zip{Is} where Is<:Tuple{Base.AbstractBroadcasted, Vector{Float64}}), ::Tuple{Tuple{Any, Any}, Int64}) where {K, V} (0 children)
   backedges: 1: superseding merge!(d::AbstractDict, others::AbstractDict...) @ Base abstractdict.jl:224 with MethodInstance for merge!(::AbstractDict, ::AbstractDict) (1126 children)

inserting merge(d::OrderedCollections.OrderedDict, others::AbstractDict...) @ OrderedCollections ~/.julia/dev/OrderedCollections/src/ordered_dict.jl:488 invalidated:
   mt_backedges: <38 invalidations I deleted because they have enormous types>
   backedges: 1: superseding merge(d::AbstractDict, others::AbstractDict...) @ Base abstractdict.jl:359 with MethodInstance for merge(::AbstractDict, ::Base.Pairs{Symbol, Union{}, Nothing, @NamedTuple{}}) (21 children)
              2: superseding merge(d::AbstractDict, others::AbstractDict...) @ Base abstractdict.jl:359 with MethodInstance for merge(::AbstractDict, ::Base.Pairs{Symbol, _A, Nothing, A} where {_A, A<:NamedTuple}) (2489 children)
```

Partial alternative to JuliaLang#61329. I added `mergewith()` and `mergewith!()`
to be on the safe side.
adienes pushed a commit that referenced this pull request Apr 7, 2026
…ang#61516)

Hopefully enough to fix JuliaC on `aarch64-linux`
(https://buildkite.com/julialang/julia-master/builds/56266#019d6367-fc8d-4806-a1f1-00ec67370c77/L1315-L1319):
```
Error #2: unresolved call from statement string(
  getproperty(
    libquadmath::Any,
    :path::Symbol
  )::Any
)::Any
 
Stacktrace:
[1] __init__()
@ CompilerSupportLibraries_jll ./CompilerSupportLibraries_jll/src/CompilerSupportLibraries_jll.jl:158
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants