Adapt to LLVM.jl 9.8.1: pass explicit JITDylib to lookup

[vchuravy]

Summary

• lookup(jljit, name) is deprecated in LLVM.jl 9.8.0+ to adapt to [jitlayers] add missing JD parameter to remaining external API call JuliaLang/julia#60988
• Pass explicit JITDylib to both lookup call sites in src/compiler/orcv2.jl
• Bump LLVM compat bound to 9.8.1

Cousin-PR to JuliaGPU/GPUCompiler.jl#796

🤖 Generated with Claude Code

[github-actions]

Your PR requires formatting changes to meet the project's style guidelines.
Please consider running Runic (git runic main) to apply these changes.

Click here to view the suggested changes.

diff --git a/src/compiler/orcv2.jl b/src/compiler/orcv2.jl
index 17dbb340..5cc1a7a8 100644
--- a/src/compiler/orcv2.jl
+++ b/src/compiler/orcv2.jl
@@ -170,7 +170,7 @@ function add_trampoline!(jd, (lljit, lctm, ism), entry, target)
     mu = LLVM.reexports(lctm, ism, jd, [alias])
     LLVM.define(jd, mu)
 
-    LLVM.lookup(lljit, jd, entry)
+    return LLVM.lookup(lljit, jd, entry)
 end
 
 function prepare!(mod)
@@ -293,7 +293,7 @@ end
 
 function lookup(name)
     lljit = jit[].jit
-    LLVM.lookup(lljit, JITDylib(lljit), name)
+    return LLVM.lookup(lljit, JITDylib(lljit), name)
 end
 
 end # module

[github-actions]

Benchmark Results

	main	9e8e093...	main / 9e8e093...
basics/make_zero/namedtuple	0.0534 ± 0.0019 μs	0.0518 ± 0.0021 μs	1.03 ± 0.055
basics/make_zero/struct	0.275 ± 0.0054 μs	0.276 ± 0.0059 μs	0.995 ± 0.029
basics/overhead	4.03 ± 0.01 ns	4.34 ± 0.01 ns	0.928 ± 0.0031
basics/remake_zero!/namedtuple	0.223 ± 0.0088 μs	0.224 ± 0.012 μs	0.994 ± 0.067
basics/remake_zero!/struct	0.227 ± 0.0084 μs	0.226 ± 0.0095 μs	1 ± 0.056
fold_broadcast/multidim_sum_bcast/1D	10.3 ± 0.25 μs	10.2 ± 0.21 μs	1.01 ± 0.032
fold_broadcast/multidim_sum_bcast/2D	12.2 ± 0.27 μs	12.1 ± 0.27 μs	1 ± 0.031
time_to_load	1.09 ± 0.0025 s	1.11 ± 0.012 s	0.981 ± 0.011

Benchmark Plots

A plot of the benchmark results has been uploaded as an artifact at https://github.com/EnzymeAD/Enzyme.jl/actions/runs/25788306744/artifacts/6965634733.

[wsmoses]

is the dylib something generated a new each time? this feels wrong if so then

[wsmoses]

@vchuravy without this PR doctests are red causing chaos. I'm going to merge for now to unblock CI.

Can you address this in post commit?