Create MLIR linker tool

[akshithg]

@xlauko I'm interested in taking a shot at this, any help/direction you can provide me?

[pgoodman]

I strongly believe linking should be a process that queries an API to get answers about how to proceed, and should not bake in specific mechanics. So, for example, if two functions have the same name, then they are linking candidates, but an API call should tell us if we can actually substitute one for the other, or not. APIs should also advise on how to rename, if at all. Finally, types (especially typedefs) will be uniquely challenging. VAST's representation of typedefs are abstraction-breaking in some ways. Typedefs are associated with MLIRContext-deduplicated named types, but a variable of typedef type takes on a different meaning depending on its usage context, because there may be an typedef operation in scope that provides a definition.

[lkorenc]

Hi and thanks for taking interest in our project! :)

So this is a rather big task and there will be a bunch of interesting problems to solve, but one step at a time. Depending on how the progress goes we can later track separate sub-issues as separate github issues, but the course of action for now I would recommend is (each step can be one PR for example):

• [ ] Create a skeleton to host the whole functionality. I would advise vast-link as a driver (among others so you can invoke something to test stuff) and appropriate library - include/vast/link for example - to host the actual logic. Ideal use case would be vast-link a.mlir b.mlir nothing fancy required - we have some other drivers you can look at how to parse cmd args etc.
• [ ] Handle a case when someone wants to link multiple modules without any conflicts. This will naturally force you/us to build some set of helpers to move mlir around + create a basic library API to build upon and will be generally useful later.
• [ ] Pick some small "problem set" and start chipping at it (we can brainstorm later what a good candidate for this will be) - but for example a case when one file has a declaration and other a definition and these should be merged.

There is absolutely no reason to bother with super complex cases this early on, we will slowly get there naturally as code adds up. As for codestyle, we do not have a guideline right now I believe, just look at the code around :) There is CONTRIBUTING.md at the root of the project that gives rules on how git is used.

Feel free to ask questions, I am happy to help.

[akshithg]

Thanks for breaking this down for me @lkorenc. As a first task I'll look at other drivers and create the skeleton for vast-link that does the bare minimum arg parsing. Will reach out if something comes up :)

[lkorenc]

Hi,

is there any progress/problems we can help with?