Unexpected Crash using `Forward`

[g-bauer]

I encountered unexpected behavior with a function and I am unsure what the issue is (compiled via cargo +enzyme run --release)

// this crashes
#[autodiff(df2f, Forward, Const, Dual, Dual)]
pub fn _f2(x: &[f64], y: f64) -> f64 {
    let xy: Vec<_> = x.iter().map(|xi| xi / y).collect();
    xy.iter().sum()
}

// this works
#[autodiff(df4f, Forward, Const, Dual, Dual)]
pub fn _f4(x: &[f64], y: f64) -> f64 {
    x.iter().fold(0.0, |acc, xi| acc + xi / y)
}

Error message:

source_id: DefId(0:13 ~ enzyme_playground[95ff]::_f2)
rustc: /code/rust/src/llvm-project/llvm/lib/IR/Instructions.cpp:686: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(Args.size() == FTy->getNumParams() || (FTy->isVarArg() && Args.size() > FTy->getNumParams())) && "Calling a function with bad signature!"' failed.

[ZuseZ4]

Ok, if you have two functions with the same signature and only one crashes, I tend to blame it on Enzyme core. Can you try my new debug docs here and let me know if they are unclear and you run into issues? If all goes well it should give you a minimal llvm-ir reproducer which we can then post in the Enzyme core repo for Billy to fix. Afterwards I'll update the enzyme submodule and it should work.

[g-bauer]

Proper example to reproduce the issue:

#![feature(autodiff)]
#[autodiff(df2f, Forward, Const, Dual, Dual)]
#[no_mangle]
pub fn _f2(x: &[f64], y: f64) -> f64 {
    let xy: Vec<_> = x.iter().map(|xi| xi / y).collect();
    xy.iter().sum()
}

fn main() {
    df2f(&[1.0], 1.0, 1.0);
}

Here is the link to the Enzyme Explorer after following your instructions in the debug docs.

[g-bauer]

Is there anything I have to consider when re-building the compiler? I pulled the latest changes and recompiled but I end up with the same error.

[ZuseZ4]

Uhm, not really. You can try rm -rf build/x86_64-unknown-linux-gnu/enzyme (adjusted for your arch) and then rebuild to be really sure, but it shouldn't be needed. Can you afterwards redo the automated minimization and check if the two reduced .ll files are the same? Maybe you're unlucky and ran into a slightly similar error case that's not covered by the last patch. Billy also mentioned we might need more than one round of fixes here.