EnzymeAD / EnzymeAD/Enzyme

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

Open
#2,961 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
LLVM
Stars
1.7k
Forks
188
Avg merge
1d 22h
Merged PRs (30d)
26

Description

## 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

```mlir
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], ret_activity = [#enzyme], 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](https://github.com/EnzymeAD/Enzyme/pull/2955).

Contributor guide

Open the contributing guide

Research direction

Start by running test/MLIR/ForwardMode/batched_derivative_constant.mlir and confirm the reproducer's module-verification failure. Trace the shared MLIR generator for zero-operand floating constants, using the issue's derivative shadow type and vectorization-state descriptions as search targets. Done means the regression passes without a second broadcast and the generated constant has the width-forward shadow type.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.