Replace the interpreter with an LLVM compiler #508
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Inkwell is updated to the latest version on crates.io, and we now require LLVM 15. Arch Linux appears to no longer include the LLVM static libraries (see https://bugs.archlinux.org/task/77691 and the mentioned bugs), so I guess it's finally time to also move over my desktop to Fedora (which does provide the necessary files). The LLVM code generation is updated to work with LLVM 15's opaque pointers setup, but I'm pretty sure I messed things up here and there. My plan for next week is to apply the new type checker and get rid of the old type checking code, fix any issues this may reveal, this get back to the LLVM code generator. |
yorickpeterse
added
compiler
yorickpeterse
force-pushed
the
native-compiler
branch
5 times, most recently
from
a98f6ef to
2c80248
Compare
yorickpeterse
force-pushed
the
native-compiler
branch
5 times, most recently
from
54ca824 to
054012e
Compare
yorickpeterse
force-pushed
the
native-compiler
branch
9 times, most recently
from
a9f20bf to
da82178
Compare
yorickpeterse
force-pushed
the
native-compiler
branch
8 times, most recently
from
c44dfa9 to
6e1d17f
Compare
yorickpeterse
force-pushed
the
native-compiler
branch
from
6e1d17f to
2174b4f
Compare
yorickpeterse
force-pushed
the
native-compiler
branch
from
2174b4f to
10a2397
Compare
Closed
yorickpeterse
force-pushed
the
native-compiler
branch
4 times, most recently
from
ac403c3 to
692e916
Compare
This was referenced May 15, 2023
Closed
yorickpeterse
added a commit
that referenced
this pull request
May 15, 2023
This replaces the bytecode interpreter with a native code compiled,
backed by LLVM. While this is a massive change, various internals remain
the same. For example, for generics we still rely on runtime pointer
checking and checks. This is a deliberate choice to keep the scope of
changes from expanding even more, and we'll take care of these remaining
issues separately.
As part of these changes we've removed the libffi based FFI, as it makes
no sense to use this API in a native code compiler. As introducing a new
FFI is going to be a lot of work, we'll also take care of this
separately, meaning you temporarily won't be able to interact with C
code.
The package manager (ipm) is also merged into the compiler executable
("inko"), removing the need for a separate command.
For more information, see #508.
yorickpeterse
force-pushed
the
native-compiler
branch
from
692e916 to
ebc4e5b
Compare
This replaces the bytecode interpreter with a native code compiled,
backed by LLVM. While this is a massive change, various internals remain
the same. For example, for generics we still rely on runtime pointer
checking and checks. This is a deliberate choice to keep the scope of
changes from expanding even more, and we'll take care of these remaining
issues separately.
As part of these changes we've removed the libffi based FFI, as it makes
no sense to use this API in a native code compiler. As introducing a new
FFI is going to be a lot of work, we'll also take care of this
separately, meaning you temporarily won't be able to interact with C
code.
The package manager (ipm) is also merged into the compiler executable
("inko"), removing the need for a separate command.
For more information, see #508.
yorickpeterse
force-pushed
the
native-compiler
branch
from
ebc4e5b to
69e0896
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a recreation of #497 so we have a cleaner comment history, making it a little easier to add notes over time. The original GitLab merge request is located here.
This pull request replaces the Rust based interpreter with an LLVM native code compiler. The motivation for this is explained here.
An explicit non-goal at this time is providing a good native code compiler, instead we're focusing "just" getting rid of the interpreter. This means that we're not focusing on optimisations, a good debugging experience, etc.
For generics we're also sticking with the old approach of basically not specialising functions and doing dynamic dispatch everywhere. This isn't great, but changing this at this time would require even more work. My long-term vision is to specialise by "kinds" or shapes rather than types, as type specialisation won't make sense given most values are heap allocated and thus represented as pointers. The mentioned "kinds" would be:
ref TTfor heap allocated valuesTvalues (String,Channeland processes)This allows us to generate specialised methods/types where this makes sense (e.g.
ref TandTuse different code for aliasing and dropping aliases). This requires quite a bit of work though, hence it's not included in this PR.Closes #83, closes #88, closes #117, fixes #317, closes #318, closes #330, closes #332, fixes #351, fixes #516, fixes #361, closed #512, fixes #509, fixes #503, fixes #362.