Support llvm-16

[kanishka-karan]

Hello,

Thanks a lot for the project!

I'm wondering if you are upgrading RuSTy to support llvm-16.

Thank You

[ghaith]

Hello,
we recently started discussing this internally. We would like to move to a newer llvm (possibly 18, but we might stick with 16). We internally need to upgrade our inkwell dependency as well. It is not something that will happen overnight but it is on the current roadmap.

[kanishka-karan]

Thanks for the response,

I would like to help, Can you please help me getting started. With inkwell what all dependencies we need to look at for upgrading of llvm-14 to llvm-16.

I tried to build rusty for llvm-16 but I am getting issues.

I changed the Cargo.toml

[root@localhost:/home/dev/rusty]$ git diff Cargo.toml
diff --git a/Cargo.toml b/Cargo.toml
index c42c712445..08f0afa247 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -17,6 +17,7 @@ default = []
 verify = []

 [dependencies]
+llvm-sys = "160.2.1"
 plc_source = { path = "./compiler/plc_source" }
 plc_ast = { path = "./compiler/plc_ast" }
 plc_util = { path = "./compiler/plc_util" }
@@ -84,7 +85,7 @@ members = [
 default-members = [".", "compiler/plc_driver", "compiler/plc_xml"]

 [workspace.dependencies]
-inkwell = { version = "0.2", features = ["llvm14-0"] }
+inkwell = { version = "0.2", features = ["llvm16-0"] }
 encoding_rs = "0.8"
 encoding_rs_io = "0.1"
 log = "0.4"

Error we are getting

   Compiling deranged v0.3.11
error[E0432]: unresolved import `inkwell::values::CallableValue`
  --> src/codegen/generators/expression_generator.rs:7:88
   |
7  |         ArrayValue, BasicMetadataValueEnum, BasicValue, BasicValueEnum, CallSiteValue, CallableValue,
   |                                                                                        ^^^^^^^^^^^^^
   |                                                                                        |
   |                                                                                        no `CallableValue` in `values`
   |                                                                                        help: a similar name exists in the module: `CallSiteValue`
   |
note: found an item that was configured out
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/inkwell-0.2.0/src/values/mod.rs:27:40
   |
27 | pub use crate::values::callable_value::CallableValue;
   |                                        ^^^^^^^^^^^^^
note: the item is gated here
  --> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/inkwell-0.2.0/src/values/mod.rs:26:1
   |
26 | #[cfg(not(any(feature = "llvm15-0", feature = "llvm16-0")))]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Compiling num v0.4.3
   Compiling crossbeam-epoch v0.9.18
   Compiling url v2.5.4
   Compiling serde_urlencoded v0.7.1
   Compiling base64 v0.21.7
   Compiling mime v0.3.17
   Compiling zerocopy v0.7.35
   Compiling sync_wrapper v0.1.2
   Compiling ipnet v2.10.1
   Compiling rayon-core v1.12.1
   Compiling reqwest v0.11.27
   Compiling crossbeam-deque v0.8.6
   Compiling fraction v0.13.1
   Compiling time v0.3.37
error[E0277]: the trait bound `inkwell::values::PointerValue<'_>: BasicType<'_>` is not satisfied
    --> src/builtins.rs:852:40
     |
852  |     let dim = builder.build_struct_gep(vla, 1, "dim").unwrap();
     |                       ---------------- ^^^ the trait `BasicType<'_>` is not implemented for `inkwell::values::PointerValue<'_>`
     |                       |
     |                       required by a bound introduced by this call
     |
     = help: the following other types implement trait `BasicType<'ctx>`:
               BasicTypeEnum<'ctx>
               inkwell::types::ArrayType<'ctx>
               inkwell::types::FloatType<'ctx>
               inkwell::types::IntType<'ctx>
               inkwell::types::PointerType<'ctx>
               inkwell::types::StructType<'ctx>
               inkwell::types::VectorType<'ctx>

I have copied only few lines.

Please help me, how we can proceed further.

Thank You.

[ghaith]

So llvm 16 introduced a big change with pointer values, this is probably what you are facing here. Pointers in llvm 16 no longer have types. I think inkwell was working on a feature flag to enable the old behavior in 0.6 but it's still not merged. TheDan64/inkwell#570 for now, this means to upgrade to llvm-16 we need to support opaque pointers. Which is a pretty big refactor. I'm assuming that the feature flag you use (llvm-16) disables the PointerValue and probably replaces it with an equivalant type that is opaque. I would start looking there. I'm not sure what happened to the CallableValue but i assume it has similar issues.

[kanishka-karan]

Thank You for your reply,
The inkwell feature for disabling opaque pointers on LLVM 15 and 16 is merged into master branch.

I am trying to build RuSTy tag v0.2.0 with inkwell master branch.

The changes done on Cargo.toml

$ git diff Cargo.toml
diff --git a/Cargo.toml b/Cargo.toml
index 4ae89bd17a..5dba65278b 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -18,9 +18,10 @@ debug = []
 verify = []

 [dependencies]
+llvm-sys = "160.2.1"
 logos = "0.12.0"
 inkwell = { git = "https://github.com/TheDan64/inkwell", branch = "master", features = [
-    "llvm14-0",
+    "llvm16-0", "typed-pointers",
 ] }
 thiserror = "1.0"
 clap = { version = "3.0", features = ["derive"] }

$ git diff libs/stdlib/Cargo.toml
diff --git a/libs/stdlib/Cargo.toml b/libs/stdlib/Cargo.toml
index 8f4ceb79e2..92b6199839 100644
--- a/libs/stdlib/Cargo.toml
+++ b/libs/stdlib/Cargo.toml
@@ -21,7 +21,7 @@ path = "../../"
 [dev-dependencies.inkwell]
 git = "https://github.com/TheDan64/inkwell"
 branch = "master"
-features = ["llvm14-0"]
+features = ["llvm16-0", "typed-pointers"]

 [dependencies]
 chrono = "0.4"

But while building I am getting below error.

# cargo build
    Updating crates.io index
error: failed to select a version for `inkwell`.
    ... required by package `iec61131std v0.1.0 (/home/dev/inkwell-git/rusty/libs/stdlib)`
versions that meet the requirements `*` (locked to 0.1.1) are: 0.1.1

the package `iec61131std` depends on `inkwell`, with features: `llvm16-0` but `inkwell` does not have these features.


failed to select a version for `inkwell` which could resolve this conflict

I also tried to build inkwell from same source and it was building fine with same features.

$ cargo build --features llvm16-0,typed-pointers
   Compiling proc-macro2 v1.0.94
   Compiling memchr v2.7.4
   Compiling semver v1.0.26
   Compiling unicode-ident v1.0.18
   Compiling regex-syntax v0.8.5
   Compiling shlex v1.3.0
   Compiling cc v1.2.16
   Compiling aho-corasick v1.1.3
   Compiling quote v1.0.39
   Compiling lazy_static v1.5.0
   Compiling syn v2.0.100
   Compiling regex-automata v0.4.9
   Compiling libc v0.2.170
   Compiling thiserror v1.0.69
   Compiling inkwell v0.5.0 (/home/dev/inkwell-git/inkwell)
   Compiling either v1.15.0
   Compiling once_cell v1.21.0
   Compiling regex v1.11.1
   Compiling llvm-sys v160.2.1
   Compiling thiserror-impl v1.0.69
   Compiling inkwell_internals v0.10.0 (/home/dev/inkwell-git/inkwell/internal_macros)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.10s

$ ls target/debug/
build  deps  examples  incremental  libinkwell.d  libinkwell.rlib

Please let me know if I am missing anything.

Thanks You,

[ghaith]

the diffs look a bit strange to me are you on rusty master?
The thing is we don't have an inkwell dependency in stdlib
And the Cargo.toml entry for inkwell should be in the workspace section.
That being set, after updating the dependencies you might want to run a cargo update.
llvm_sys should not be required unless you want to explicitly use it but you should not have to.

All in all, after you get inkwell dependencies correctly there will be some changes required to bring rusty to the newest inkwell api, mostly in codegen inkwell added result types for all operations that might fail. We were doing result types previously so now we have to expect a result anywhere we were handling the errors ourselves. It is probably easiest as a first step to just unwrap wherever you encouter an error (or use expect with a message we could track). This should be fine for 90% of the cases since we should not fail on codegen. We usually block the compilation during validation.
If you do notice failures in tests due to the unwraps, you could convert the errors into Diagnostics and propagate them up.

[ghaith]

oh, I just noticed you said tag 0.2.0. You probably just need a cargo update there and inkwell should be fetched from master. Keep in mind this is a very old state of the compiler.

[kanishka-karan]

Thank You
cargo update worked

[kanishka-karan]

Hi,
Thank you for the support!
Is support for opaque pointers in RuSTy on the roadmap ?
If yes, can you please help me with the time lines.

Thank You Again.