EnzymeAD / Enzyme

High-performance automatic differentiation of LLVM and MLIR.
https://enzyme.mit.edu
Other
1.27k stars 108 forks source link

C++20 non-type template parameter wrapper not working for lambdas with captures #1685

Open alecjacobson opened 8 months ago

alecjacobson commented 8 months ago

I was trying to follow the examples and probably misunderstood the documentation. I guess the documentation is ambiguous whether "Using a similar wrapper with non-type template parameter (requires C++20)" will work for lambdas that capture.

This little examples seems to show that it won't: https://enzyme.mit.edu/explorer/

Could anyone please confirm?

wsmoses commented 8 months ago

Ah, so we definitely should improve those docs (PR's welcome and cc'ing @samuelpmish @samuelpmishLLNL).

Lambda's that capture essentially can be thought of as a function that doesn't capture, followed by that passes in the lambda data as the first argument. As a result, the lambda with data requires a marking for enzyme_const, enzyme_dup, enzyme_out, etc.

The example in the doc with c++20 may work if the data in the lambda is a compile time constant, but otherwise you can't push runtime data through a template argument. It is resolvable (like mentioned above), but that specific wrapper would need some modification.

We have been meaning to add better overall syntactic sugar for C++ (akin to the Julia ones https://enzyme.mit.edu/julia which have type wrappers and automatically handle closures/members, etc), but we've recently been distracted by things like auto sparsity :)

samuelpmishLLNL commented 8 months ago

hi @alecjacobson -- I'm a fan of your work on TetWild!


Thanks for finding this mistake. For reference, here's the relevant bit of the documentation if you have any other corrections or contributions. A coworker of mine recently found a small syntax mistake in one of the code snippets on that page, so I should probably fix that one too.

I assumed that stateful lambdas as nontype template args were valid C++20 (unrelated to enzyme), and gcc agrees but clang doesn't: https://godbolt.org/z/8xTs8sfTx. Ultimately, clang's opinion is the only one that counts here!