You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a set of operations post-compilation that we need to do, that I'm lumping together and calling "linking":
On a most basic level, libcore and user code will be compiled separately, into two spir-v modules, that will need to be combined.
1.1) On a more realistic level, rustc "codegen units" compile crates into possibly more than a dozen modules, plus linking in external crates.
Dead code elimination
Capability computation - auto-detect what capabilities the module is using and add those to the module, check to make sure the actual capabilities are what the user expected. (very important to do this after DCE)
Other potential weird processing stuff we need to hack together (for example, for a bit there might have needed to be a pass to clean up OpTypeForwardPointers, but turns out that's not needed)
There's two options that we could do:
Re-use the spirv-tools linker, in c++, then implement DCE etc. in another pass after the linker
Write our own linker, and link and DCE etc. at the same time with the same code
2 seems to be much more reasonable, because it seems like we're going to have to implement a lot of that complexity anyway, and having exact control over the quirks seems extremely useful - and our output is certainly going to be quirky.
The linker has all the core functionality implemented, so closing this. If we want to track any particular (larger) task/issue in the linker, we should open a more specific issue with a clear end goal.
There's a set of operations post-compilation that we need to do, that I'm lumping together and calling "linking":
1.1) On a more realistic level, rustc "codegen units" compile crates into possibly more than a dozen modules, plus linking in external crates.
There's two options that we could do:
2 seems to be much more reasonable, because it seems like we're going to have to implement a lot of that complexity anyway, and having exact control over the quirks seems extremely useful - and our output is certainly going to be quirky.
@Jasper-Bekkers is currently working on this.
The text was updated successfully, but these errors were encountered: