I’m missing where S-expressions come in. Meaning, what changes due to this. I think it is the “what do you want to achieve” part I’m missing
Is the idea to represent the entire Swift language in MLIR? Have it be a frontend for a specific domain? Make it easy to target via Swift’s function builders? (I assume you know Eugene and Alex’s work there. Represent SIL (effectively) as a dialect etc.
Some good progress there which you may have seen on the other threads/code. And I believe @GeorgeL was also looking at that area from Swift side.
The way I see it, Swift bindings for MLIR is actually two projects: The first is simply binding the MLIR C API, and the second is creating a TableGen backend to generate Swift code for arbitrary dialects. I’ve made some good progress on the first bit, but haven’t yet begun to tackle the second bit. My work is not currently in a shareable state, but it wouldn’t be too hard to clean it up enough so that other folks can play around with it after reading a long disclaimer . I’d also be happy to jump on a call at some point and chat about what you are working on.
In response to your other question, I’m by no means an expert on MLIR, but the way I see it “Swift on MLIR” would involve a set of dialects. Some of the lower-level things are likely handled by existing dialects, but we would almost certainly need to create new dialects for the various higher level Swift concepts.
OK, so insert-long-disclaimer-here, but I’ve cleaned up my Swift bindings project enough to let folks take a look. I removed any dependencies on commits to LLVM I haven’t yet upstreamed, but as of this writing check-mlir fails for me on master. The most recent commit I’ve used that works is 29807a023ce.
I would love for whoever-is-interested to take a look (@ftynse@stellaraccident: no pressure, but if you’ve been wondering why I’ve been bugging you so much here it is ). The code is still a little rough and specific to my use case, but I think it is good enough to serve as a basis for discussion of what Swift bindings for MLIR should look like. I’m not committed to any of the design decisions I’ve made up to this point, and I’m very interested in more folks getting involved so I would love to hear your thoughts!
I think this might be a typo, and the target should be X86 (with a capital X). I was using “host” before but needed to pick a specific one when I unwound some of my other LLVM changes, so hopefully we can make it easier to choose different targets in the future.
I work for Stella Lorenzo at Google and would like to chat with you about your work and the Swift work I’ve been doing this year. I’m new on the forum, so I don’t seem to be able to message you directly yet.
Not sure who is still interested, but I just pushed a big update to the bindings (GitHub - GeorgeLyon/MLIRSwift: MLIR Bindings for Swift), and updated it to work with a recent MLIR commit. There are a number of improvements, not the least of which is a new ownership system, which tracks whether an MLIR value is owned by Swift or MLIR using generics. This project is getting pretty close to a point where I’d love to start getting feedback, so if you are curious I encourage you to take a look!