Differentiate the CUDA memcpy family in forward mode

[wsmoses]

Neither the driver API (cuMemcpy{HtoD,DtoH,DtoD}[Async][_v2], and the unified
cuMemcpy[Async]) nor the runtime API (cudaMemcpy[Async]) had a derivative,
so staging data through device memory failed outright. This is the error
reported in EnzymeAD/Enzyme.jl#3442:

No forward mode derivative found for cuMemcpyDtoHAsync_v2

A CUDA transfer behaves exactly like a memcpy, except that the shadow copy has
to go back through the CUDA API rather than becoming an llvm.memcpy, since at
least one side generally lives in memory the host cannot address. So rather
than a parallel implementation, visitMemTransferCommon grows an optional
emitter hook: the CUDA path reuses its type segmentation, activity handling and
zeroing of inactive float sources, and only the emission of the copy differs.

Type analysis learns to propagate the pointee type between the two sides, that
a CUdeviceptr is a pointer despite being an integer, and to stop marking
trailing arguments as integers before the stream pointer a CUDA transfer
carries where a memcpy carries only volatility.

Reverse mode still reports a missing derivative rather than answering
incorrectly; accumulating into device memory needs a copy that runs on the
device, which cannot be emitted from the host.

Testing

Three lit tests — driver API, runtime API, and the ejlstr$fn$lib naming a
frontend may use — plus Integration/ForwardMode/cudamemcpy.cpp, which checks
the tangent numerically against a mocked CUDA runtime and confirms both the
primal and the shadow are transferred each way. Passes -O0 through -O3.

Full unit suite on LLVM 16: 1193 pass, 11 xfail, 1 fail — that failure is
ReverseModeVector/partial_int_window.ll, which fails identically on unmodified
main with this local LLVM 16 build. Format (clang-format 16) and
check_emission_order.py clean.

Relationship to the other PRs

Split up at review request; this one is now just the transfer derivatives.

• Declare helper entry points under the caller's naming convention #3111 (merged) — getOrInsertPerCallingConv and the pre-existing call sites
  that needed it.
• Recognize the CUDA deallocations #3112 (merged) — recognizing the CUDA deallocations, which these tests rely on
  because they free the device buffers they allocate.
• Deliver the forward-mode tangent of a cuBLAS _v2 scalar result #3113 — the cuBLAS _v2 forward-mode scalar result. Independent of this;
  can land in either order.

Remaining gaps in EnzymeAD/Enzyme.jl#3442 after all four: cublasGemmEx is not
recognized by extractBLAS; a forward-mode shadow placeholder for a cmpxchg
result is never replaced, tripping the verifier inside CUDA.jl's memory pool;
and the shadow chain for a CuArray breaks at Managed{DeviceMemory}, which is
type-inactive because DeviceMemory is an untyped byte buffer.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R6a8BiaAKpUTgP86mQ9ZKP