Expand description
Definitions shared by macros / syntax extensions and e.g. rustc_middle
.
Modules§
- This crate handles the user facing autodiff macro. For each
#[autodiff(...)]
attribute, we create anAutoDiffItem
which contains the source and target function names. The source is the function to which the autodiff attribute is applied, and the target is the function getting generated by us (with a name given by the user as the first autodiff arg). - This module contains the definition of the
TypeTree
andType
structs. They are thin Rust wrappers around the TypeTrees used by Enzyme as the LLVM based autodiff backend. The Enzyme TypeTrees currently have various limitations and should be rewritten, so the Rust frontend obviously has the same limitations. The main motivation of TypeTrees is to represent how a type looks like “in memory”. Enzyme can deduce this based on usage patterns in the user code, but this is extremely slow and not even always sufficient. As such we lower some information from rustc to help Enzyme. For a full explanation of their design it is necessary to analyze the implementation in Enzyme core itself. As a rough summary,-1
in Enzyme speech means everywhere. That is{0:-1: Float}
means at index 0 you have a ptr, if you dereference it it will be floats everywhere. Thus* f32
. If you have{-1:int}
it means int’s everywhere, e.g. [i32; N].{0:-1:-1 float}
then means one pointer at offset 0, if you dereference it there will be only pointers, if you dereference these new pointers they will point to array of floats. Generally, it allows byte-specific descriptions. FIXME: This description might be partly inaccurate and should be extended, along with adding documentation to the corresponding Enzyme core code. FIXME: Rewrite the TypeTree logic in Enzyme core to reduce the need for the rustc frontend to provide typetree information. FIXME: We should also re-evaluate where we create TypeTrees from Rust types, since MIR representations of some types might not be accurate. For example a vector of floats might be represented as a vector of u8s in MIR in some cases.