'LLVM ERROR: Expected a constant shift amount!' when compiling for avr-atmega328p #523
Comments
|
This looks like a bug in LLVM, this error should be unreachable. What version of rustc are you using? There was a recent upgrade to LLVM 16 that was reverted. if (!isa<ConstantSDNode>(N->getOperand(1))) {
// 32-bit shifts are converted to a loop in IR.
// This should be unreachable.
report_fatal_error("Expected a constant shift amount!");
} |
|
I am using nightly 1.70: I will try using an older nightly version, and I'll edit this comment with the results. Edit: I hadn't noticed this before but the example project demonstrated on that tutorial includes a |
|
I am facing the same problem. |
|
Might be fixed by #522. |
|
#522 is not intended to fix this issue, but seeing as I have the AVR toolchain installed, I'll take a look. That being said, I'm not able to duplicate this issue with the following compiler and the default generated project: $ rustc +nightly -Vv
rustc 1.70.0-nightly (44f518058 2023-03-20)
binary: rustc
commit-hash: 44f5180584404d18058cbbf224c55255db4fdcbb
commit-date: 2023-03-20
host: x86_64-pc-windows-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7After programming, I have a working blinky. ScrollbackWilliam@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE
$ cargo generate --git https://github.com/Rahix/avr-hal-template.git
Unable to load config file: C:\Users\William\.cargo\cargo-generate.toml
Project Name : avr-shl
Generating template ...
✔ Which board do you use? · Arduino Uno
[ 1/19] Done: .cargo\config.toml
[ 2/19] Done: .cargo
[ 3/19] Done: .gitignore
[ 4/19] Done: Cargo.toml
[ 5/19] Done: LICENSE-APACHE
[ 6/19] Done: LICENSE-MIT
[ 7/19] Done: README.md
[ 8/19] Done: avr-specs\avr-atmega1280.json
[ 9/19] Done: avr-specs\avr-atmega168.json
[10/19] Done: avr-specs\avr-atmega2560.json
[11/19] Done: avr-specs\avr-atmega328p.json
[12/19] Done: avr-specs\avr-atmega32u4.json
[13/19] Done: avr-specs\avr-atmega48p.json
[14/19] Done: avr-specs\avr-attiny85.json
[15/19] Done: avr-specs\avr-attiny88.json
[16/19] Done: avr-specs
[17/19] Done: rust-toolchain.toml
[18/19] Done: src\main.rs
[19/19] Done: src
Moving generated files into: `C:\msys64\home\William\Projects\MCVE\avr-shl`...
Initializing a fresh Git repository
Done! New project created C:\msys64\home\William\Projects\MCVE\avr-shl
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE
$ cd avr-shl/
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ rm rust-toolchain.toml
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ cargo +nightly build
Compiling compiler_builtins v0.1.87
Compiling core v0.0.0 (C:\Users\William\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\core)
Compiling proc-macro2 v1.0.54
Compiling unicode-ident v1.0.8
Compiling quote v1.0.26
Compiling syn v1.0.109
Compiling rustversion v1.0.12
Compiling proc-macro-hack v0.5.20+deprecated
Compiling paste v1.0.12
Compiling avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling ufmt-macros v0.2.0
Compiling avr-device-macros v0.5.0
Compiling rustc-std-workspace-core v1.99.0 (C:\Users\William\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\src\rust\l
ibrary\rustc-std-workspace-core)
Compiling nb v1.1.0
Compiling void v1.0.2
Compiling cfg-if v1.0.0
Compiling vcell v0.1.3
Compiling bare-metal v1.0.0
Compiling ufmt-write v0.1.0
Compiling nb v0.1.3
Compiling avr-device v0.5.0
Compiling ufmt v0.1.2
Compiling embedded-hal v0.2.7
Compiling embedded-storage v0.2.0
Compiling cfg-if v0.1.10
Compiling panic-halt v0.2.0
Compiling atmega-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling arduino-hal v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling avr-shl v0.1.0 (C:\msys64\home\William\Projects\MCVE\avr-shl)
Finished dev [optimized + debuginfo] target(s) in 32.00s
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ avrdude -patmega328p -carduino -PCOM5 -b57600 -Uflash:w:target\\avr-atmega328p\\debug\\avr-shl.elf:e
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "target\avr-atmega328p\debug\avr-shl.elf"
avrdude.exe: writing flash (306 bytes):
Writing | ################################################## | 100% 0.21s
avrdude.exe: 306 bytes of flash written
avrdude.exe: verifying flash memory against target\avr-atmega328p\debug\avr-shl.elf:
Reading | ################################################## | 100% 0.19s
avrdude.exe: 306 bytes of flash verified
avrdude.exe done. Thank you.
William@DESKTOP-3H1DSBV MINGW64 ~/Projects/MCVE/avr-shl
$ |
|
I just published a new version of compiler-builtins, can you try updating the version in rust-lang/rust to see if this fixes your problem? |
|
I already am preparing a PR to upgrade compiler-builtins, so I'll test to see that this issue is fixed as well while I'm at it. |
|
Updating to william@xubuntu-dtrain:~/Projects/MCVE/avr-shl$ LD_LIBRARY_PATH=/home/william/Projects/toolchains/build-llvm-toolchain/build-llvm/lib/ cargo +msp430-fix build -Zbuild-std=core
Compiling compiler_builtins v0.1.91
Compiling core v0.0.0 (/home/william/Projects/toolchains/build-llvm-toolchain/build-rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/core)
Compiling proc-macro2 v1.0.54
Compiling quote v1.0.26
Compiling unicode-ident v1.0.8
Compiling syn v1.0.109
Compiling rustversion v1.0.12
Compiling proc-macro-hack v0.5.20+deprecated
Compiling paste v1.0.12
Compiling avr-hal-generic v0.1.0 (https://github.com/rahix/avr-hal?rev=4c9c44c314eb061ee20556ef10d45dea36e75ee4#4c9c44c3)
Compiling avr-device-macros v0.5.0
Compiling ufmt-macros v0.2.0
Compiling rustc-std-workspace-core v1.99.0 (/home/william/Projects/toolchains/build-llvm-toolchain/build-rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling nb v1.1.0
LLVM ERROR: Expected a constant shift amount!
error: could not compile `compiler_builtins` (lib)
warning: build failed, waiting for other jobs to finish... |
|
I'm sympathetic to the AVR Rust use case, so I went and did a bisect. This is indeed an LLVM issue. The commit that introduced the bug is llvm/llvm-project@840d10a cc: @aykevl My |
The most recent functional version I could find is |
|
Oops, I didn't expect that to happen but I have a patch that should fix this. It's not very small though. |
|
@aykevl Is there any workaround that can be applied locally for the time being, or "just wait until you get your patch into upstream LLVM"? If the latter, could you link the relevant Phabricator page when you submit? I can probably take care of the cherry-picking part into Rust's copy of LLVM once your patch is upstream. |
|
I have pushed my changes here: llvm/llvm-project@main...aykevl:llvm-project:avr-shift-loop Feel free to submit these to Phabricator on my behalf. I'm not currently working on the AVR backend (sorry!). The patches should be mostly ready for review, although the "subreg liveness" patch may need a bit of cleanup. (Side note: I believe that while this issue now results in an assertion, previously it would result in emitting symbols like |
|
Unfortunately, getting these patches into LLVM is not a time commitment I can currently undertake (not this month at least). Cherry-picking from Phabricator for Rust's version of LLVM is different, as I've done this several times in the past. In comparison, I have no experience submitting patches to Phabricator. If the patches require cleanup, someone else who is familiar w/ the AVR backend will have to get these patches upstream for the time being (or someone will have to bring me up to speed on the AVR backend/LLVM in general). |
Uses the most recent version of nightly toolchain that compiles AVR targets. A regression in LLVM causes rustc to fail when compiling AVR targets. See: rust-lang/compiler-builtins#523
|
building as release works for me in 1.71.0 (current nightly). |
Still fails for me against Does adding: to |
|
I’ve already done that, without I run out of registers. |
|
The defining difference between debug build failing and release build succeeding seems to be Tested with |
Nightly builds compile with the current version release (2023-05-15). Adding `codegen-units = 1` fixes compilation errors for debug builds. See: rust-lang/compiler-builtins#523 (comment)
Nightly builds compile with the current version release (2023-05-15). Adding `codegen-units = 1` fixes compilation errors for debug builds. See: rust-lang/compiler-builtins#523 (comment)
Probably because the code changed in a way that it doesn't hit the faulty code path. I'm pretty sure the bug can still occur with |
|
adding |
I think so too, but so far it seems to avoid this issue. I hope this helps someone more knowledgeable to find the issue and for the rest of us to get the code compiling. But as you say no guarantees. |
There is a fix, see my earlier comment here: #523 (comment). |
|
Thanks for the patch @aykevl, I'll try to review and submit it over the next few days 🙂 |
|
Okie, patch tested & submitted: Once it's merged, I'll take care of bumping Rust's llvm-project and let know back. |
|
Looks like llvm/llvm-project@ff75a2b has landed but there's more diffs en route? |
|
Yea, the most important revision (and hopefully the last one) is https://reviews.llvm.org/D153197 - I'll take another stab at it at Saturday / Sunday (to address the comment from benshi001). |
Nightly builds compile with the current version release (2023-05-15). Adding `codegen-units = 1` fixes compilation errors for debug builds. See: 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
|
Status: fixed on LLVM's side - will be solved when LLVM's version is bumped here (apparently soon ™️ ). |
|
fwiw, this got fixed with rust-lang/rust#114048 🙂 |
Uses the most recent version of nightly toolchain that compiles AVR targets. A regression in LLVM causes rustc to fail when compiling AVR targets. See: rust-lang/compiler-builtins#523
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
When compiling the default project generated with
cargo generate --git https://github.com/Rahix/avr-hal-template.git(following this tutorial), an LLVM error arises:I have tried searching for this error online and have found zero mentions of it, even outside the context of Rust.
The
-vvargument produces the following output (trimmed to only show relevant compilations):As you may have seen from the log files, I am using NixOS and I have a suspicion this is part of the problem. I have the appropriate toolchains installed, but I don't know if I've got them all:
Any pointers towards the cause of this issue would be greatly appreciated. Thank you for your time 😄
The text was updated successfully, but these errors were encountered: