-
-
Notifications
You must be signed in to change notification settings - Fork 290
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
base: main
Are you sure you want to change the base?
Conversation
update nixpkgs to 24.05 fixup
409b54c
to
c47915a
Compare
@@ -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); |
There was a problem hiding this comment.
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.
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"); |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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.
const RocStr = @import("./bitcode/src/str.zig").RocStr; | ||
const RocDec = @import("./bitcode/src/dec.zig").RocDec; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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.
if main_fn.verify(true) { | ||
function_pass.run_on(&main_fn); | ||
} else { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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}" |
There was a problem hiding this comment.
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.
// include libc | ||
"--library", | ||
"c", |
There was a problem hiding this comment.
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
.
@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.
I also think we should start using |
New PR on main sounds good! |
We should merge #6859 first before this PR. |
No description provided.