Enzyme: adapt to pending version breaking update

[wsmoses]

No description provided.

[maleadt]

Use [only downstream].

[wsmoses]

@maleadt okay corresponding Enzyme version has been released

[maleadt]

Enzyme.jl tests didn't run here because of the LLVM.jl v9.1 blacklist, so this PR was not tested.

[wsmoses]

ah right.... okay I'll see if I can quickly fix that

[wsmoses]

we've now released a 9.1 compatible version

[wsmoses]

@maleadt @vchuravy CI seems to complain with a chicken and egg problem.

So at this point enzyme has compat with all the latest llvm and GPUCompiler and ought be compatible with enzyme……but can’t be solved by pkg due to KA. But the KA pkg testing requirea cuda to accept the enzyme bump which means this has to have already gone in for KA to bump, and so on

[maleadt]

CI testing can/should use master branches. And I'm fine being the first one to merge if you have verified this locally.

[wsmoses]

so @maleadt I think this was broken by #2472 in a way that I don't quite understand how to fix?

[maleadt]

You'll have to elaborate what the problem is; I'm not familiar with Enzyme.jl (and by extension any of the code in this PR). #2472 simply added a kwarg to the kernel's call method indicating if it should call cudaconvert or not. It uses a Val instead of a simple boolean because it uses the value as part of the @generator; defaulting to true for HostKernels and to false for DeviceKernels.

[wsmoses]

@maleadt okay this now passes locally on cyclops, if this can get a merge then tag