Calling jl_value_ptr has inlining cost of 20 even when its optimized out

[Zentrik]

I'm on master (#51892), but I see same results on 1.9.3 and 1.10.0-beta3.

julia> function test(d)
             return Base.pointer_from_objref(d)
       end
test (generic function with 1 method)

julia> d = IdDict((3=>5))
IdDict{Int64, Int64} with 1 entry:
  3 => 5

julia> @code_llvm test(d)
; Function Signature: test(Base.IdDict{Int64, Int64})
;  @ REPL[7]:1 within `test`
define i64 @julia_test_3355({}* noundef nonnull align 8 dereferenceable(24) %"d::IdDict") #0 {
top:
;  @ REPL[7]:2 within `test`
  %coercion = ptrtoint {}* %"d::IdDict" to i64
  ret i64 %coercion
}

julia> Base.print_statement_costs(stdout, test, Tuple{typeof(d)})
test(d) @ Main REPL[7]:1
 20 1 ─ %1 = $(Expr(:foreigncall, :(:jl_value_ptr), Ptr{Nothing}, svec(Any), 0, :(:ccall), Core.Argument(2)))::Ptr{Nothing}
  0 └──      return %1

Even though the call is optimized out there is still an inlining cost, I thought this comment said it was fixed, #41461 (comment) but I can reproduce that issue.

[Zentrik]

Should jl_value_ptr be added here like jl_string_ptr?

julia/base/compiler/optimize.jl

Lines 1105 to 1110 in 98542d7

	elseif head === :foreigncall
	foreigncall = ex.args[1]
	if foreigncall isa QuoteNode && foreigncall.value === :jl_string_ptr
	return 1
	end
	return 20

[vtjnash]

Probably not. jl_value_ptr is harmful to the compiler for optimizations and correctness. The jl_string_ptr function should be removed eventually, but doesn't change compilation much since it only references constant memory.