codegen: add a pass for late conversion of known modify ops to call atomicrmw

[vtjnash]

The ExpandAtomicModify can recognize our pseudo-intrinsic julia.atomicmodify and convert it into some of known atomicrmw expressions, or simplify it with more inlining, as applicable. Ideally we could get this pass upstreamed, since there's nothing specific to julia about this pass, and LLVM's IR cannot express this quite correctly without making it a new intrinsic.

This ensures that now our @atomic modify is as fast as Threads.Atomic!

julia> @code_llvm Threads.atomic_add!(r, 10)
; Function Signature: atomic_add!(Base.Threads.Atomic{Int64}, Int64)
;  @ atomics.jl:307 within `atomic_add!`
define i64 @"julia_atomic_add!_2680"(ptr noundef nonnull align 8 dereferenceable(8) %"x::Atomic", i64 signext %"v::Int64") #0 {
top:
; ┌ @ Base_compiler.jl:94 within `modifyproperty!`
   %0 = atomicrmw add ptr %"x::Atomic", i64 %"v::Int64" acq_rel, align 8
; └
; ┌ @ Base_compiler.jl:54 within `getproperty`
   ret i64 %0
; └
}

[gbaraldi]

Why is there such a large aotcompile.cpp diff? Looks unrelated

[vtjnash]

Why is there such a large aotcompile.cpp diff? Looks unrelated

It is mostly support code for this, since if you don't have the IR emitted for the target, then it has to use a loop&call, which isn't want people want to see, so we need to make sure to emit the target code too into all of the correct compile units. We could land some of it separately, but it wouldn't do anything (be mostly untested) until this landed

[oscardssmith]

Is this ready to merge? Edit: no. CI seems pretty unhappy with this currently.

[DilumAluthge]

Also there's a merge conflict.

[vtjnash]

Please review, but hold off on merging. I think there might be one other PR I try to merge first

[oscardssmith]

CI failures look real: Specifically the following seems to be a multithreading test that breaks with this PR:

threads_exec.jl with JULIA_NUM_THREADS == 1,0: Test Failed at /cache/build/tester-demeter6-15/julialang/julia-master/julia-67ad4b675e/share/julia/test/threads_exec.jl:444
  Expression: accum[] + Int(var[]) === sum(0:nloops)
   Evaluated: 129821317250305000 === 500500