ran out of registers for AVR atmega4809 #112140
Comments
apiraino
added
O-wasm
|
@rustbot label O-avr |
Noratrieb
changed the title
|
digging some more... using different nightly versions at least from nightly-2023-02-28 to nightly-23-03-21 it will SIGSEGV with this error nightly-2023-03-22 and later it seems to run out of registers. with following error. |
|
Please add this to your Cargo.toml [profile.release]
lto = trueand tell me if it builds in |
Thanks for your response ! no sadly this does not build either.. |
|
huh, that usually fixes things. |
|
For now I did get it to work using nightly-2022-10-22 using --release not using the lto setting, so for now I can compile, while it still fails without --release but not on current release with --release and lto set to true, I will update you on the error as I cant remember it, im not at my workstation at the moment. Kind Regards, |
|
Hi, the error message when compiling without ... is kinda expected because AVR is such a tiny target platform that unoptimized Rust code simply wouldn't fit there - I don't think there's much Rust / LLVM can do (maybe except for improving the error message somehow). (( edit: although apparently The other error, though: ... is suspicious; I'll try to take look over the weekend 🙂 |
|
Okie, that's a regression on LLVM's side: I'll try to review that patch and submit it to LLVM folks. |
this indeed seems logical.. a better errors would indeed be nice though.. ...
[profile.release]
lto = true
codegen-units = 1
[build]
target = "./avr-4809.json"
[unstable]
build-std = ["core"]with as a result .. using the same settings with nightly-2022-10-22 seems to compile. |
|
Progress: patch tested & submitted (rust-lang/compiler-builtins#523 (comment)). |
Currently our AVRShiftExpand pass expands only 32-bit shifts, with the assumption that other kinds of shifts (e.g. 64-bit ones) are automatically reduced to 8-bit ones by LLVM during ISel. However this is not always true and causes problems in the rust-lang runtime. This commit changes the logic a bit, so that instead of expanding only 32-bit shifts, we expand shifts of all types except 8-bit and 16-bit. This is not the most optimal solution, because 64-bit shifts can be expanded to 32-bit shifts which has been deeply optimized. I've checked the generated code using rustc + simavr, and all shifts seem to behave correctly. Spotted in the wild in rustc: rust-lang/compiler-builtins#523 rust-lang/rust#112140 Reviewed By: benshi001 Differential Revision: https://reviews.llvm.org/D154785
|
This should be fixed now with LLVM 17! |
Currently our AVRShiftExpand pass expands only 32-bit shifts, with the assumption that other kinds of shifts (e.g. 64-bit ones) are automatically reduced to 8-bit ones by LLVM during ISel. However this is not always true and causes problems in the rust-lang runtime. This commit changes the logic a bit, so that instead of expanding only 32-bit shifts, we expand shifts of all types except 8-bit and 16-bit. This is not the most optimal solution, because 64-bit shifts can be expanded to 32-bit shifts which has been deeply optimized. I've checked the generated code using rustc + simavr, and all shifts seem to behave correctly. Spotted in the wild in rustc: rust-lang/compiler-builtins#523 rust-lang/rust#112140 Reviewed By: benshi001 Differential Revision: https://reviews.llvm.org/D154785
and others
Good day..
I have been trying to compile some code for a atmega4809, following the rust embedded book.
but im running into quite some problems,..
used the following device jsons with either atmega4809 || avrxmega3 cpu setting,
pack was downloaded from the official place
{ "arch": "avr", "atomic-cas": false, "cpu": "atmega4809", "data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8", "eh-frame-header": false, "env": "", "exe-suffix": ".elf", "executables": true, "late-link-args": { "gcc": [ "-lgcc" ] }, "linker": "avr-gcc", "linker-is-gnu": true, "llvm-target": "avr-unknown-unknown", "code-model": "small", "max-atomic-width": 8, "no-default-libraries": false, "os": "unknown", "pre-link-args": { "gcc": [ "-mmcu=atmega4809", "-B./packs/gcc/dev/atmega4809/" ] }, "target-c-int-width": "16", "target-endian": "little", "target-pointer-width": "16", "vendor": "unknown" }.cargo/config.tomlwhile using nightly-2022-10-22 it gives me a SIGSEGV with release tag
while using nightly-2022-10-22 without --release
using nightly-2022-12-08 without --release gives again a SIGSEGV
using nightly-2022-12-08 with --release
using latest nighly-2023-05-30 with --release
using latest nighly-2023-05-30 without --release
anyone know how to solve this..?
The text was updated successfully, but these errors were encountered: