-
Notifications
You must be signed in to change notification settings - Fork 51
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
Julia does not support cross-compilation to 32-bits #486
Comments
I suspect running with opaque pointers in Julia 1.10 should probably resolve this, as the pointer size is not hard-coded into the IR. |
Offsets will still be wrong... We may be able to fix this in Julia proper, but right now cross-compilation from 64bit to 32bit is not a supported feature. |
I was wondering if that might be the answer (can't compile from 64 bit to 32 bit). For this case, I can make things work by setting the pointer size back to 64 bits in the data layout: GPUCompiler.llvm_datalayout(::WASMTarget) = "e-m:e-p:64:32:32-i64:32:32-f64:32:64" Then, Julia generates correct IR, and LLVM compiles to WebAssembly okay. That's probably a kludge and not a real solution. |
When accessing fields, Julia can either:
The second is what you want for cross compiling. I've actually had better luck with the first for WebAssembly. I think the first is done for mutable structs, and the second is done for immutable structs. I haven't figured out the rules though (here, I think). Using a 32-bit version of Julia doesn't solve the problem. A 32-bit version of Julia can have a different data layout than 32-bit WebAssembly, so the offsets are different. Julia is just not set up well for cross compiling. |
With opaque pointers gep will also use byte offsets, we haven't turned on opaque pointers, but eventually we must. Might be Julia 1.11 |
I'm trying to work out some kinks in the WebAssembly support in StaticCompiler. The main issue is addressing nested structs when I'm compiling on a 64-bit version of Julia. Here's an example that illustrates the problem:
Here's the result of that.
The problem is the
getelementptr
line. At the end, there is ai32 2
. It should be a 1 instead of a 2 because it should be pointing at the second component of the nested struct using zero-based indexing.I've tried some variations:
Anyone have hints or suggestions on how to track down the issue or correct an error in this?
The text was updated successfully, but these errors were encountered: