Integration with llvm-ir crate?

[cdisselkoen]

Hi,

Someone else just pointed this repo out to me and it looks great! I noticed in your README that some of the higher-level representation of LLVM IR is listed as todo. As the maintainer of the llvm-ir crate, I'm of course very interested in this; it seems like our crates might be able to work well together, with yours having the capability to parse LLVM bitcode in pure Rust, and mine having a high-level interface to LLVM IR. I guess my question is have you considered integrating with llvm-ir, and if there's anything in llvm-ir that you would want to see changed or done differently to work with your use case. I'm a volunteer maintainer but if there are things you'd like to see in llvm-ir I'm interested to hear.

[woodruffw]

Hi there!

I love that idea -- it looks like you've put an incredible amount of effort into providing high-quality Rust mappings for LLVM's IR, which would save me a correspondingly incredible amount of time :-)

I'll have a clearer picture of what I'd like to see in llvm-ir as I continue to work on the next stage of this project, which involves mapping the bitstream's entities into the kinds of models that llvm-ir provides. I'll try not to be too hard on your time -- I'm a volunteer maintainer (for this) too, and I should be able to put in PRs for most things!

[woodruffw]

I found a first potential touchpoint between our two ecosystems! Both the high level (IR) and low level (bitstream) representations need to be able to reference a variety of constants/enums, like the valid calling convention constants.

It looks like llvm-ir currently provides a bunch of those, like here. However, I can't depend directly on llvm-ir within the bitstream parsing components, since llvm-ir requires llvm-sys and that would defeat the point of a pure Rust implementation.

To whit: what do you think both ecosystems using the llvm-constants crate as a common dumping ground for these kinds of constants/enums? That would keep the dependency tree clean on my side + allow me to derive convenience traits like TryFromPrimitive for use within the mapper, and llvm-ir could re-export those constants/enums to preserve API compatibility.

[woodruffw]

(One slightly tricky thing is that llvm_ir::function::CallingConvention is an opaque enumeration over LLVMCallConv, whereas the lower components will need to reference a direct, same-valued enumeration. So perhaps it's not the best starting example 😅.)

[cdisselkoen]

I think I have an idea for a cleaner approach. llvm-ir could make its llvm-sys dependency optional, and also have an optional dependency on one or more of the mollusc crates. Users of llvm-ir could then choose between llvm-sys and mollusc for bitcode parsing, via a Cargo feature. llvm-ir::function::CallingConvention would have both the current implementation to construct it using llvm_sys::LLVMCallConv, and a new implementation to construct it from an llvm_constants::CallingConvention. Essentially the code to convert from the low-level mollusc representation to llvm-ir would live in the llvm-ir crate alongside (and as an alternative to) the llvm-sys code. I think it makes more sense for the high-level representation crate to depend on the low-level representation crate than vice versa, anyway.

In your particular example, this also allows llvm-ir to keep its CallingConvention as an opaque enumeration, while mollusc has the same-valued enumeration which better befits a low-level interface.

Thoughts on this? Am I off base?

[woodruffw]

That sounds much cleaner! Yeah, that’ll keep the concerns much more separate. Sent from mobile. Please excuse my brevity.

…

On Aug 14, 2021, at 12:21 PM, Craig Disselkoen ***@***.***> wrote:  I think I have an idea for a cleaner approach. llvm-ir could make its llvm-sys dependency optional, and also have an optional dependency on one or more of the mollusc crates. Users of llvm-ir could then choose between llvm-sys and mollusc for bitcode parsing, via a Cargo feature. llvm-ir::function::CallingConvention would have both the current implementation to construct it using llvm_sys::LLVMCallConv, and a new implementation to construct it from an llvm_constants::CallingConvention. Essentially the code to convert from the low-level mollusc representation to llvm-ir would live in the llvm-ir crate alongside (and as an alternative to) the llvm-sys code. I think it makes more sense for the high-level representation crate to depend on the low-level representation crate than vice versa, anyway. In your particular example, this also allows llvm-ir to keep its CallingConvention as an opaque enumeration, while mollusc has the same-valued enumeration which better befits a low-level interface. Thoughts on this? Am I off base? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.