cc @rxwei @marcrasi

I'll re-pitch the idea of creating a top-level SILDifferentiableFunctionType with explicit component original & JVP & VJP SILFunction types.

This representation is much less memory-efficient and harder to parse and printing. But it is explicit, so all of these reabstraction and "conservation" and phase ordering (commutative diagram) issues.

The current representation implicitly infers JVP & VJP function types (particularly the differential and pullback types) from the original function type's parameter and result conventions. It may be possible to fix all the bugs here: so that the inference is consistent everywhere, respecting phase ordering, working for both differentiable_function construction and differentiable_function_extract extraction. But that seems like a lot of work, and I'm not confident it will be clean (hack-free) and easy to understand. For example, function-type optimizations (on @differentiable closure values in SIL) may need to be conservative to prevent invariants about the bundled types from being broken.

@swift-ci create

IMO that is an overly heavyweight solution and will explore other possible approaches.

That's fair. Look forward to more elegant ideas, happy to discuss!

I think the lightweighter version of the idea above is storing TangentVector parameter and result conventions for pullback (and maybe also differential) functions in SIL @differentiable function types. It's these conventions that cannot be reliably inferred - no need to store extra parameter and result types.

Yes, that's exactly what I had planned to try. Currently we have SILParameterDifferentiability and SILResultDifferentiability for each function type parameter and result. We can compress differentiability and parameter/result convention into a single word.