MLIR: width-forward AD mishandles zero-operand derivative constants

[jacobleft]

Summary

MLIR derivative generation can emit a zero-operand floating constant into a width-forward tangent expression with an inconsistent vectorization state.

The generated constant must use the derivative shadow type rather than the primal result type. Once it does, the generator must also report that the value is already vectorized; otherwise the generic vectorization path broadcasts it a second time.

Minimal reproducer

func.func @atan(%x: tensor<4xf32>) -> tensor<4xf32> {
  %0 = math.atan %x : tensor<4xf32>
  return %0 : tensor<4xf32>
}

func.func @main(%x: tensor<4xf32>, %dx: tensor<2x4xf32>) -> tensor<2x4xf32> {
  %0 = enzyme.fwddiff @atan(%x, %dx) {activity = [#enzyme<activity enzyme_dup>], ret_activity = [#enzyme<activity enzyme_dupnoneed>], width = 2 : i64} : (tensor<4xf32>, tensor<2x4xf32>) -> tensor<2x4xf32>
  return %0 : tensor<2x4xf32>
}

The derivative's literal 1 is operand-less. Without the fix, it is emitted as tensor<4xf32> and derivative construction fails while forming an arith.addf with tensor<2x4xf32>. With the fix, it is emitted as tensor<2x4xf32> and the module verifies.

The executable regression is test/MLIR/ForwardMode/batched_derivative_constant.mlir.

Failure modes

1. A primal-shaped constant is combined with a width-forward tangent, producing an invalid operation with incompatible operand types.
2. A shadow-typed constant that is still reported as non-vectorized gains a second width dimension when the generic vectorization path broadcasts it.

Expected behavior

A zero-operand floating constant in a derivative expression has the derivative shadow type and is treated as vectorized whenever that shadow type carries width.

Scope

This is a generic MLIR derivative-codegen and vectorization-state issue. The reproducer exercises one derivative rule; the change is in the shared generator for every zero-operand floating constant.

Related closed attempt: EnzymeAD/Enzyme#2955.