Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linker #27

Closed
khyperia opened this issue Sep 10, 2020 · 1 comment
Closed

Linker #27

khyperia opened this issue Sep 10, 2020 · 1 comment
Assignees

Comments

@khyperia
Copy link
Contributor

There's a set of operations post-compilation that we need to do, that I'm lumping together and calling "linking":

  1. 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.
  2. Dead code elimination
  3. 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)
  4. 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:

  1. Re-use the spirv-tools linker, in c++, then implement DCE etc. in another pass after the linker
  2. 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.

@Jasper-Bekkers is currently working on this.

@repi repi changed the title Linker tracking issue Linker Sep 10, 2020
@repi repi mentioned this issue Sep 10, 2020
@repi repi mentioned this issue Sep 18, 2020
@khyperia
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants