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

Remove LLVM dependency from front end #1074

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

koliyo
Copy link
Contributor

@koliyo koliyo commented Oct 10, 2023

For the Hylo LSP server we only need the front end of the compiler. This would also remove the dependency on LLVM, both for building, and especially as runtime link dependency.

In order to remove LLVM from Hylo Core I have copied the enum types used Core.NativeInstruction

In addition I have added a HyloFrontEnd build product.

@koliyo koliyo force-pushed the feature/frontend-remove-llvm-dependency branch from 792a941 to b8a81f6 Compare October 10, 2023 18:15
@kyouko-taiga
Copy link
Contributor

For the Hylo LSP server we only need the front end of the compiler.

While that is currently true, I don't think it will remain so in the future. I'm planning to use LLVM as a JIT compiler to evaluate compile-time expressions during type checking.

Is the LLVM dependency blocking your progress on the LSP implementation?

@koliyo
Copy link
Contributor Author

koliyo commented Oct 20, 2023

Ok, yeah the compile time JIT evaluation makes a lot of sense for a modern programming language for sure!

For the LSP development it is mainly an issue of packaging the vscode extension + LSP for end user distribution.

My current approach is that the LSP server should be self contained, and not depend on specific libraries being installed on the user machine. And LLVM adds a pretty large set of explicit and implicit libraries as dependencies.

An alternative approach would be that the LSP depends on an existing Hylo compiler installation, but this Hylo distribution is not available yet.

And I still prefer if the hylo LSP would be self contained, but that is up for discussion.

Anyway, without LLVM the hylo LSP distribution is relatively straightforward right now.

  • Mac, single binary, swift runtime libraries will be available
  • Linux, build fully static library, with swift runtime embedded.
  • Windows, not sure if building static library is possible (?), right now I copy the swift runtime dlls as part of the distribution artifacts.

LLVM will add quite a lot to this, just the llvm.dylib on my mac is 145MB, and it has additional transitive dependencies.

Additionally there is some reduction in overhead in CI workflows, avoiding installation of LLVM and some reduced compilation time. But the CI setup is manageable, that is not the main concern.

Anyway, I think I will use the LLVM-free build for now, either if the PR is merged, otherwise I will keep this patch in my fork. And when the JIT part of the frontend becomes implemented I can revisit this topic.

As always, windows is the most trouble since it does not have any defacto concept of package management.

On linux we could probably use existing package managers, and on Mac maybe assume some homebrew environment. This will need some further discussion and design at some point.

@kyouko-taiga
Copy link
Contributor

Thanks a lot for your answers and sorry for the delay to come back.

An alternative approach would be that the LSP depends on an existing Hylo compiler installation, but this Hylo distribution is not available yet.

I like this suggestion. I think we should start exploring how to make that distribution. There's been some talks with @nickpdemarco at some point. I can't take the lead on this task but happy to assist in any way I can.

And I still prefer if the hylo LSP would be self contained, but that is up for discussion.

My sense is that if you're developing Hylo you'll need a compiler anyway. So I feel justified asking people to refer to their local toolchain to get a VScode extension running.

Anyway, I think I will use the LLVM-free build for now, either if the PR is merged, otherwise I will keep this patch in my fork. And when the JIT part of the frontend becomes implemented I can revisit this topic.

That is fair. The JIT integration is not very far on the roadmap by the way. Once we've nailed necessary support for decent generics I'm planning to look into generic value arguments.

On linux we could probably use existing package managers, and on Mac maybe assume some homebrew environment. This will need some further discussion and design at some point.

As I personally don't want to install Homebrew on my system I would be reluctant to assume such an environment for others. Perhaps we could stand up a bare bone installation script for macOS and Windows (and even Linux). That thing could grow with community contributions as problems show up.

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

Successfully merging this pull request may close these issues.

2 participants