codegen: Propagate ipo_purity_bits to LLVM function attributes

[IanButterworth]

Updated after @gbaraldi (who previously explored this in #47844) helped out:

Translate Julia's inferred effects (consistent, effect_free, nothrow, terminates, notaskstate) into LLVM function attributes so that middle-end passes like GVN, LICM, and DSE can exploit them.

The key design insight is that GC interactions don't need to be visible before GC lowering. Call-site declarations get optimistic memory attributes (e.g. memory(argmem: read)) that enable pre-GC optimizations, then LateLowerGCFrame widens them to memory(readwrite) before safepoint analysis so post-GC passes see correct semantics.

Attributes added:

• nounwind: for nothrow functions (with uwtable(async) on definitions
  to preserve .eh_frame for stack scanning)
• mustprogress: for terminating functions
• willreturn: for nothrow+terminating functions
• memory(argmem: read): for consistent+effect_free functions with no
  user-facing pointer arguments (call-site declarations only)
• speculatable: for the above when also nothrow+terminating Not used
• readnone on gcstack param: for notaskstate functions, so LICM can
  hoist pure calls past heap stores
• "julia.safepoint" marker: on all call-site declarations, used by
  LateLowerGCFrame to identify and widen optimistic attrs

LateLowerGCFrame strips all optimistic attributes (memory effects,
readnone on gcstack) from both call instructions and function
declarations before safepoint analysis runs.

Developed with Claude

[oscardssmith]

I'm pretty sure @gbaraldi had a previous version of this PR. The really hard part is iirc, From LLVM's point of view, some of the things that we consider effect free are effect-full.

[IanButterworth]

Ah ok! I didn't find anything that looked similar. Note that macOS tests passed.
(I'm not currently sure why Test.jl isn't precompiling on other platforms)

[oscardssmith]

I think it's #50188

[giordano]

Comparing to the Rust equivalent

How did you compile the Rust code? By default rustc doesn't do an optimised build, which makes performance comparisons very misleading.

[gbaraldi]

The memory read ones are potentially illegal because they ignore the safe point

[IanButterworth]

How did you compile the Rust code?

@giordano it was with -o (mentioned in the table), which is opt-level 3

[vchuravy]

The memory read ones are potentially illegal because they ignore the safe point

The issue is that we can't reorder writes across function calls due to safepoints. if LLVM moves a store to a pointer past a function call we potentially miss a rooting event.

[oscardssmith]

I think it might be a good idea to experiment with LLVM's gcwrite for pointer stores since it would make these sorts of optimizations legal (since gcwrite carries the writebarrier with it automatically). Doing so would potentially give us stackmaps for "free"

[IanButterworth]

Ok. Just to summarize

• The main perf gain here (memory(argmem: read)) isn't legal in this form
• The nounwind thing only seems to be valid on macOS aarch64 (and I didn't look into how much perf gain this alone gives)

So the current PR, even if it disabled those two, doesn't seem to have much merit.

[gbaraldi]

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

[vchuravy]

Is this enough to LICM calls. Like sin?

[IanButterworth]

Maybe not? Some benchmarking locally

bench_ipo_effects.jl.txt

[IanButterworth]

Because of !n ?

[oscardssmith]

yeah LLVM can't licm functions that may throw. I really think DomainError was a mistake (and we should return NaN), but we obviously can't fix that now. I have thought about introducing Base.NaNMath which the "normal" math functions would then add DomainErrors to so that users could get the good version easily if they want it.

[nanosoldier]

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

[Zentrik]

I guess this will subsume #51120 as well

[giordano]

We probably need a few llvm pass tests to make sure the optimisations don't disappear with an llvm bump?

[IanButterworth]

@gbaraldi I just force pushed because my email was wrong and picking up another author. also drop an unrelated whitespace change in Test.jl

[IanButterworth]

Disabling emission of speculatable changes the ziggurat regression into to an improvement

Note: I explored adding a cheap effect and gating speculatable on it, but didn't get the performance back with that approach IanButterworth@83cd7ed

[IanButterworth]

@gbaraldi confirmed with the LLVM folk that they never infer speculatable, so I disabled it

[IanButterworth]

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

[nanosoldier]

The benchmark job you requested has completed - possible performance regressions were detected. 4818 benchmarks were executed, 120 showed regressions, and 127 showed improvements.
Commits: 7fb9330 vs 3181c36
The full report is available.

[IanButterworth]

Using the benchmark plot summary code from JuliaCI/Nanosoldier.jl#227 on #61394 (comment)

[IanButterworth]

I couldn't reproduce those biggest regressions locally on mac.

@gbaraldi good to merge?

[giordano]

Is this enough to LICM calls. Like sin?

While it doesn't do LICM on sin (but it does on exp, because it doesn't throw), it already does common subexpression elimination also on sin and cos:

julia> code_llvm((Float64,); debuginfo=:none) do x sin(x) * sin(x) + cos(x) * cos(x) end

; Function Signature: var"#92"(Float64)
define double @"julia_#92_0"(double %"x::Float64") local_unnamed_addr #0 {
top:
  %0 = call double @j_sin_0(double %"x::Float64") #10
  %1 = fmul double %0, %0
  %2 = call double @j_cos_0(double %"x::Float64") #10
  %3 = fmul double %2, %2
  %4 = fadd double %1, %3
  ret double %4
}

This is going to make code involving rotation matrices a lot simpler to write: you can repeat those sin(θ) and cos(θ) calls multiple times without fear 😁 Compare with nightly

julia> code_llvm((Float64,); debuginfo=:none) do x sin(x) * sin(x) + cos(x) * cos(x) end

; Function Signature: var"#50"(Float64)
define double @"julia_#50_0"(double %"x::Float64") local_unnamed_addr #0 {
top:
  %0 = call double @j_sin_0(double %"x::Float64")
  %1 = call double @j_sin_0(double %"x::Float64")
  %2 = fmul double %0, %1
  %3 = call double @j_cos_0(double %"x::Float64")
  %4 = call double @j_cos_0(double %"x::Float64")
  %5 = fmul double %3, %4
  %6 = fadd double %2, %5
  ret double %6
}

---

Also fastmath code can be better optimised with this PR:

julia> code_llvm((Float64,); debuginfo=:none) do x; @fastmath sin(x) - sin(x) end

; Function Signature: var"#101"(Float64)
define double @"julia_#101_0"(double %"x::Float64") local_unnamed_addr #0 {
top:
  %0 = call double @j_sin_0(double %"x::Float64") #9
  ret double 0.000000e+00
}

When no-NaNs can be assumed, the compiler can simplify the code more effectively (just sad it doesn't remove the dead code, not even with exp). Compare with current nightly

julia> code_llvm((Float64,); debuginfo=:none) do x; @fastmath sin(x) - sin(x) end

; Function Signature: var"#47"(Float64)
define double @"julia_#47_0"(double %"x::Float64") local_unnamed_addr #0 {
top:
  %0 = call double @j_sin_0(double %"x::Float64")
  %1 = call double @j_sin_0(double %"x::Float64")
  %2 = fsub fast double %0, %1
  ret double %2
}

[gbaraldi]

Outside of that dangling comment it seems good