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

DO NOT MERGE Upgrade llvm 18 zig 13 #6921

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

Conversation

lukewilliamboswell
Copy link
Collaborator

No description provided.

flake.nix Outdated Show resolved Hide resolved
@@ -196,7 +196,6 @@ fn gen_from_mono_module_llvm<'a>(

let builder = context.create_builder();
let (dibuilder, compile_unit) = roc_gen_llvm::llvm::build::Env::new_debug_info(module);
let (mpm, _fpm) = roc_gen_llvm::llvm::build::construct_optimization_passes(module, opt_level);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLVM optimisation is no longer done at function level, but only at module level.

Comment on lines +262 to +274
let inkwell_opt_level = crate::target::convert_opt_level(opt_level);
let inkwell_llvm_passes = crate::llvm_passes::get_llvm_passes_str(opt_level);
let inkwell_target_machine =
crate::target::target_machine(target, inkwell_opt_level, inkwell::targets::RelocMode::PIC)
.expect("should be a valid target machine");

module
.run_passes(
inkwell_llvm_passes,
&inkwell_target_machine,
inkwell::passes::PassBuilderOptions::create(),
)
.expect("valid llvm optimization passes");
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have replaced all the locations where we use llvm optimisations with the same helpers in roc_build to get the inkwell/llvm target_machine and llvm_passes.

@@ -76,7 +76,7 @@ pub fn arch_str(target: Target) -> &'static str {
roc_target::Architecture::X86_32 if cfg!(feature = "target-x86") => "x86",
roc_target::Architecture::Aarch64 if cfg!(feature = "target-aarch64") => "aarch64",
roc_target::Architecture::Aarch32 if cfg!(feature = "target-arm") => "arm",
roc_target::Architecture::Wasm32 if cfg!(feature = "target-webassembly") => "wasm32",
roc_target::Architecture::Wasm32 if cfg!(feature = "target-wasm32") => "wasm32",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the same helpers for llvm calls surfaced this issue, we were referencing a feature that doesn't exist.

Comment on lines +5 to +6
const RocStr = @import("./bitcode/src/str.zig").RocStr;
const RocDec = @import("./bitcode/src/dec.zig").RocDec;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We moved this file, because zig 0.13.0 no longer allows relative imports from a parent/ancestor.

@@ -172,7 +184,7 @@ fn run(comptime T: type, comptime n: usize, comptime op: fn (T, T) T, v: T) u64

// This is needed to work around a bug with using `@call` in loops.
inline fn callWrapper(comptime T: type, call_modifier: anytype, comptime func: anytype, params: anytype) T {
return @call(.{ .modifier = call_modifier }, func, params);
return @call(call_modifier, func, params);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure about this change, but it seems to work just fine.

@@ -243,7 +243,7 @@ fn build_transform_caller_help<'a, 'ctx>(
let block = env.builder.get_insert_block().expect("to be in a function");
let di_location = env.builder.get_current_debug_location().unwrap();

let arg_type = env.context.i8_type().ptr_type(AddressSpace::default());
let arg_type = env.context.ptr_type(AddressSpace::default());
Copy link
Collaborator Author

@lukewilliamboswell lukewilliamboswell Aug 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since LLVM 15 pointers are not typed. Using the latest inkwell surfaces this as a warning. The fix is just to replace the ptr types with env.context.ptr_type(AddressSpace::default()) as advised by cargo check.

After making this change, there were a number of places where variables were no longer used, so I followed chippy's suggestions and removed each of these.

-    // warning: use of deprecated method `inkwell::types::FunctionType::<'ctx>::ptr_type`:
-    // Starting from version 15.0, LLVM doesn't differentiate between pointer types.
-    // Use Context::ptr_type instead.

Comment on lines -289 to -291
if main_fn.verify(true) {
function_pass.run_on(&main_fn);
} else {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand this change. I believe LLVM optimisation no longer occurs at a function level and so the function_pass manager is no longer required. Here I have removed this, but we still keep the verification check.

Request this be looked at this more closely.

@@ -32,7 +32,7 @@
vscodeWithExtensions = pkgs.vscode-with-extensions.override {
vscodeExtensions = with pkgs.vscode-extensions;
[
matklad.rust-analyzer
rust-lang.rust-analyzer
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

matklad's rust-analyser is deprecated, nix gives us an error and forces replacement with the rust-lang version.

@@ -133,7 +137,7 @@
1; # to run the GUI examples with NVIDIA's closed source drivers

shellHook = ''
export LLVM_SYS_${llvmMajorMinorStr}_PREFIX="${llvmPkgs.llvm.dev}"
export LLVM_SYS_180_PREFIX="${llvmPkgs.dev}"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LLVM MajorMinor is actually 181, but most references still want 180 so we hardcode it here.

Comment on lines -299 to -301
// include libc
"--library",
"c",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was causing issues with zig build-obj when exporting main. We had an error saying duplicate symbol.

I believe the cause of this is that now zig 0.13.0 bundles wasi-libc, and so if we include -lc we now have two main functions, one from wasi-libc for the WASI implementation because we build the host at -target wasm32-wasi and also from out host.zig.

@lukewilliamboswell lukewilliamboswell changed the title WIP Upgrade llvm 18 zig 13 Upgrade llvm 18 zig 13 Aug 14, 2024
@lukewilliamboswell
Copy link
Collaborator Author

@Anton-4 -- not urgent, just making a note while I'm looking at this

We need to update the following in CI workflows to use zig 13.

      - name: Update PATH to use zig 11
        run: |
          echo "PATH=/home/big-ci-user/Downloads/zig-linux-x86_64-0.11.0:$PATH" >> $GITHUB_ENV

I also think we should start using ROC_ZIG environment variable somehow, I don't see it in any of the CI scripts. Could we make this change against our current main, or would this be better in this PR?

@Anton-4
Copy link
Collaborator

Anton-4 commented Aug 16, 2024

I also think we should start using ROC_ZIG environment variable somehow, I don't see it in any of the CI scripts. Could we make this change against our current main, or would this be better in this PR?

New PR on main sounds good!

@lukewilliamboswell lukewilliamboswell marked this pull request as ready for review September 5, 2024 02:28
@lukewilliamboswell lukewilliamboswell changed the title Upgrade llvm 18 zig 13 DO NOT MERGE Upgrade llvm 18 zig 13 Sep 5, 2024
@lukewilliamboswell lukewilliamboswell added the blocked Prevents this PR from auto-closing after 30 days of inactivity label Sep 5, 2024
@lukewilliamboswell
Copy link
Collaborator Author

We should merge #6859 first before this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Prevents this PR from auto-closing after 30 days of inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants