Optimize PLT and jl_load_and_lookup calls

[pchintalapudi]

This removes the literal pointers from ccalls in codegen, in favor of inserting them into the JIT just before compilation. In the future, this could also permit deduplication of library and symbol globals across multiple compilation units, rather than just across a single jl_codegen_params_t as is done today. We also get prettier LLVM IR as a result.

The deferral is implemented by adding julia.fname and either julia.libname or julia.libidx attributes to each PLT global variable and each jl_lookup_and_load callsite. This allows external consumers to also implement their own recognition and transformations on ccalls.

Depends on #50678

cc @wsmoses since Enzyme probably cares about this.

[vtjnash]

style nit: delete code, do not comment it out

[vtjnash]

Why is this a property of the code itself (rather than a choice of the use site of the code)? That seems weird

[pchintalapudi]

At the moment we make different choices in imaging mode vs non-imaging mode, so I wanted to carry that over (particularly in jl_dump_native, where we guess imaging mode from the global defaults rather than from how the code was generated).

[vtjnash]

Feels rather risky to trigger this here, since you are holding many locks

[pchintalapudi]

I could release the symbols_mutex lock and perhaps one iteration of the context lock, but otherwise it's technically valid I think since we never cross a lock boundary.

[pchintalapudi]

I guess the other problem is that jl_get_library_ is not marked as not being a safepoint, is it actually a safepoint?

[vtjnash]

Yes, dlopen must be a safepoint, so this is too

[vtjnash]

FWIW, most of the ecosystem is probably deprecating code that used this pattern as soon as Elliot can finish his PR #50687

[pchintalapudi]

Isn't this code the base implementation of ccall/cglobal? How will #50687 deprecate this code?

[vtjnash]

#50687 always uses the lazy function form, so this semi-eager unpredictable case doesn't occur anymore

[pchintalapudi]

Does that apply to libjulia/libjulia-internal, or will that still rely on this (mostly I just don't like seeing call inttoptr 140234234... when really I'm looking at an array allocation).

[vtjnash]

That still relies on this, but not the dlopen call, so it doesn't have the arbitrary code execution issue

[maleadt]

@pchintalapudi This PR seems to cause a large amount of packages to fail on PkgEval. Just see the latest daily evaluation, there's many occurrences of:

julia: /source/usr/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = llvm::ConstantExpr; From = llvm::Value]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

[506] signal (6.-6): Aborted
in expression starting at /home/pkgeval/.julia/packages/JOLI/S3LJy/src/JOLI.jl:57
gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7f0dc843f40e)
__assert_fail at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
cast<llvm::ConstantExpr, llvm::Value> at /source/usr/include/llvm/Support/Casting.h:578 [inlined]
operator() at /source/src/jitlayers.cpp:1597
optimizeDLSyms at /source/src/jitlayers.cpp:2032 [inlined]
_jl_compile_codeinst at /source/src/jitlayers.cpp:230
jl_generate_fptr_impl at /source/src/jitlayers.cpp:528
jl_compile_method_internal at /source/src/gf.c:2475 [inlined]
jl_compile_method_internal at /source/src/gf.c:2363
gen_cfun_wrapper at /source/src/codegen.cpp:6090
emit_cfunction at /source/src/codegen.cpp:6727 [inlined]
emit_expr at /source/src/codegen.cpp:5564
emit_ssaval_assign at /source/src/codegen.cpp:5135
emit_stmtpos at /source/src/codegen.cpp:5370 [inlined]
emit_function at /source/src/codegen.cpp:8462

e.g. https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_date/2023-08/05/JOLI.primary.log