The metadata parser in the github discussion seems to work on debuginfo. It means that each time we want Enzyme to work, we should add a “-g” option to the compiling command “rustc”. I’m a bit in doubt whether this will be OK though it doesn’t make much difference. But will there be some cases, like running on a device whose memory is limited, where adding debuginfo do have some negative effect? Anyway, this may be the most fitting way.
Now, AIUI, there are 4 things need to be done in the project:
-
writing a parser parsing LLVM metadata and passing it to Enzyme
-
adjusting Enzyme to leverage the metadata
-
writing a Rust crate to provide APIs to Rust user
-
writing a Rust compiler patch to allow importing LLVM plugins to the Rust compiler
Is that right?
Regarding debug information, yeah it’s not necessarily the best mechanism (obviously that would be direct Rust compiler integration), but I believe it should be sufficient at least for now. Presumably, we can always run a pass that removes debug info after Enzyme if the extra information becomes a concern.
I think your understanding of the project components is mostly correct. The one thing that I might add (and of course there’s a lot here, not all of which needs completion during GSOC) is potential registration of custom derivatives for various rust internal routines/allocation mechanisms, and possibly marking explicitly the activity analysis markers of routines such as print to be inactive. The second bit is to clarify that Enzyme, by virtue of being an LLVM pass natively has support for LLVM Metadata. The specific issue here is parsing the specific layout of Rust types in the metadata into something more easily digestible to LLVM/Enzyme type analysis.
Manuel Drehwald (trying to find email and will add to cc) has recently been looking into exporting the Enzyme C API as a crate to be called from Rust. Once that exists, we can extend the Rust compiler or perhaps create a special Rust-specific optimization pass that calls the Enzyme API with the Type metadata parsing to perform end-to-end tests.
If you’re looking to dive right in, I’d probably suggest pushing either the metadata parsing or Rust plugin (or custom codegen pass) as next steps.
I have considered user-custom derivatives. I think we can define proc-macros that allows users to use their own defined derivatives (instead of ones generated by Enzyme) in this project, then the registration of frequently-used functions’ derivatives can be implemented in a separated projects.
So, if not misunderstood, the outline of the project is thus:
-
a Rust metadata parser and some modification to Enzyme to use the parsed metadata
-
a Rust-specific optimization pass or extending the Rust compiler
-
some utilities to provide handlers to Rust to implement the fore-mentioned functions, like user-defined derivatives and indicating markers
As to the Rust API, it can be implemented in Manuel Drehwald’s project. The 3rd part may seems to overlap with that, but essentially, in my idea, the 3rd part of the GSoC project will only contains the minimal set to make Enzyme function well in Rust, and the rest will be left to Manuel Drehwald’s project.
If there’s no problem, I’ll further dive into the 1st, 2nd, and 3rd part sequentially, and write a draft of the proposal soon.
Chuyang Chen
MSc Student
At Department of Computer Science and Technology, Nanjing University
