optimize: revise inlining costs #51599
Conversation
Add a bonus for Intrinsics called with mostly constant arguments. We know that simple expressions like `x*1 + 0` will get optimized later by LLVM, and also likely fold into other expressions, so try to reflect that in the cost estimated earlier. Additionally rebalance some of the other costs to more accurately reflect what they take in assembly.
| (f === Intrinsics.cglobal || f === Intrinsics.llvmcall) # these hold malformed IR, so argextype will crash on them | ||
| return cost | ||
| end | ||
| aty2 = widenconditional(argextype(ex.args[2], src, sptypes)) |
There was a problem hiding this comment.
widenconditional should be unnecessary at this phase.
There was a problem hiding this comment.
I was unsure if some external package might try to request inlining costs before we called this on everything, and I wanted to still give a consistent answer then. I think it is no-cost to be here?
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
|
The benchmark change here is whether we inline the call or dispatch the signature to call The penalty for making that choice is higher than it should be, and poorly reflected in the way we compute the inlining cost heuristics, but that is not relevant to this PR. |
|
This change broke GPUCompiler's @inline @generated function sink(i::T) where {T}
llvmcall_str = """%slot = alloca i64
store volatile i64 %0, i64* %slot
%value = load volatile i64, i64* %slot
ret i64 %value"""
return :(Base.llvmcall($llvmcall_str, T, Tuple{T}, i))
end
@eval f(x) = $(foldl((e, _) -> :($sink($e) + $sink(x)), 1:100; init=:x))
g() = f(10)
include("newinterp.jl")
@newinterp AlwaysInline
Core.Compiler.OptimizationParams(::AlwaysInline) =
Core.Compiler.OptimizationParams(; inline_cost_threshold=typemax(Int))
Base.code_ircode(g, Tuple{}; interp=AlwaysInline())@vtjnash Are we doing something fishy here, or why was this affected by this PR? |
|
Currently |
Add a bonus for Intrinsics called with mostly constant arguments. We know that simple expressions like
x*1 + 0will get optimized later by LLVM, and also likely fold into other expressions, so try to reflect that in the cost estimated earlier. Additionally rebalance some of the other costs to more accurately reflect what they take in assembly.