Expose AOT compilation in C API.

[meheff]

Add a function for compiling and generating aot metadata, and a separate function for running the code from the generated artifacts. Use ORC JIT for loading the object code.

[allight]

I don't have any serious issues with this but looking at the xlsynth-crate branch I wonder if it might be simpler to just have fork-exec the aot_compiler_main and use it that way. This is a lot of code to cram into xls-c-api.

I also wonder whether it might be easier to give the aot stuff the ability to run lld (through the c++ library) and then a lot of this gets a bunch simpler since you can have your stuff just dlopen and dlsym the library.

[meheff]

Thanks for the review, Alex. I simplified things quite a bit which I think resolves your comments:

• Removed xls_aot_run_function from the C API. This took object code and ran it with irvalues. This was more for testing than for production purposes and isn't really necessary.
• Removed the added LoadObjectCode method from OrcJit. The test now just call llvm directly to load the object code.

Regarding fork-exec'ing aot_compiler_main, this would require carrying the aot_compiler_main binary along with the library. The proto generation code is already shared with aot_compiler_main, and the object code generation is just a single function call. The rest of the code in xls_aot_compile_function is just the verbose fluff needed to do things C style (manual allocation/free).

[allight]

One minor change and LGTM.

I would like to remind you too that though we won't go around changing it for no reason the abi of our generated entrypoints shouldn't really be considered stable. We may want to change it dramatically for any number of reasons. Practically the only thing likely to be long term (relatively) stable are the external interfaces our wrapper rules create. For something more long term stable I'd really suggest having an api that you give the entrypoint pointer and metadata and it returns a handle that you can request to execute using some defined 'xls::Value' mirror in the c api. For now though this is fine.

[meheff]

One minor change and LGTM.

I would like to remind you too that though we won't go around changing it for no reason the abi of our generated entrypoints shouldn't really be considered stable. We may want to change it dramatically for any number of reasons. Practically the only thing likely to be long term (relatively) stable are the external interfaces our wrapper rules create. For something more long term stable I'd really suggest having an api that you give the entrypoint pointer and metadata and it returns a handle that you can request to execute using some defined 'xls::Value' mirror in the c api. For now though this is fine.

Thanks for the heads up and understood about no guarantee about stability. We're willing to tradeoff stability for performance here (passing in IrValues has some significant performance penalty). Since we don't live at head we can fix things as necessary when they break. We have a wrapper layer in rust which insulates end users from the xls abi details and it should be flexible enough to deal with xls-side changes.