Handle setfield! in alloc_elim_pass

[carnaval]

Probably does not come up very often but was added to allow for generic code with mutable accumulators such as

mut_zero(::Type{BigFloat}) = zero(BigFloat)
function mut_add!(x::BigFloat, y::BigFloat)
    ccall((:mpfr_add,:libmpfr), Int32, (Ptr{BigFloat}, Ptr{BigFloat}, Ptr{BigFloat}, Int32), &x, &x, &y, Base.MPFR.ROUNDING_MODE[end])
end

mut_zero(::Type{Float64}) = Ref(0.0)
mut_add!(x,y) = x[] += y
Base.convert(::Type{Float64}, r::Ref{Float64}) = r[]

then write

function sum{T}(vs::Vector{T})
    acc = mut_zero(T)
    for v in vs
        mut_add!(acc,v)
    end
    convert(T, acc)
end

and get efficient scalar code in the Float64 case

@andreasnoack

[yuyichao]

👍 I didn't do this last time because I worry being more aggressive here might make the codegen bug worse.

[JeffBezanson]

Cool!

While you're at it, it would be good to see if alloc_elim_pass can be sped up at all, since I've seen some profiles that indicate a fair amount of time is spent there.

I would also like to see comments illustrating the transformation done, i.e. showing example IR fragments and what they get converted to.

[carnaval]

While you're at it, it would be good to see if alloc_elim_pass can be sped up at all, since I've seen some profiles that indicate a fair amount of time is spent there.

do you have an example benchmark where this is particularly evident that I can use as a basis ?

I would also like to see comments illustrating the transformation done, i.e. showing example IR fragments and what they get converted to.

can do

[JeffBezanson]

It was one that @andreasnoack ran into:

a = rand(5,5);
LinAlg.generic_matmatmul!(a, 'N', 'N', a, a);

I don't think this pass is more than half the time, but I was hoping there might be low-hanging fruit there. In particular a lot of time is spent in occurs_outside_getfield.

[timholy]

With apologies for hijacking this for unrelated purposes, see #16128 (comment)

@nanosoldier runbenchmarks(ALL, vs=":release-0.4")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[vtjnash]

This looks pretty cool. The benchmarks are all over the place though: some got faster, some slower.

[jrevels]

The benchmarks are all over the place though: some got faster, some slower.

Note that Tim ran the benchmarks here against the release-0.4 branch, not master (I think at the time he didn't know that benchmarks could be run from commits, so he hijacked this PR to do a comparison).

[andreasnoack]

@nanosoldier runbenchmarks(ALL, vs=":master")

[yuyichao]

Quote?

[jrevels]

Nanosoldier doesn't accept jobs via comment edits (assuming that's what happened here). It used to, but I considered that a bug and fixed it (since it easily allowed jobs to accidentally get re-triggered, or triggered on comment deletion).

@nanosoldier runbenchmarks(ALL, vs=":master")

[andreasnoack]

Thanks and I can see that the soldier actually changes color so I should have noticed.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[andreasnoack]

@carnaval Do you have an idea why this would slow down setindex!? See https://github.com/JuliaCI/BaseBenchmarkReports/blob/2432c36d008722f869797d51d26c529ffb8b8a05/01fcea6_vs_39b9d7d/report.md

[Keno]

We have this now