rustc + avr = lovelove back again #139
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit contains a refactoring that merges AVRRelaxMemOperations into AVRExpandPseudoInsts, so that we have a single place in code that expands the STDWPtrQRr opcode. Seizing the day, I've also fixed a couple of potential bugs with our previous implementation (e.g. when the destination register was killed, the previous implementation would try to .addDef() that killed register, crashing LLVM in the process - that's fixed now, as proved by the test). Reviewed By: benshi001 Differential Revision: https://reviews.llvm.org/D122533
Currently, STDSPQRr and STDWSPQRr are expanded only during AVRFrameLowering - this means that if any of those instructions happen to appear _outside_ of the typical FrameSetup / FrameDestroy context, they wouldn't get substituted, eventually leading to a crash: ``` LLVM ERROR: Not supported instr: <MCInst XXX <MCOperand Reg:1> <MCOperand Imm:15> <MCOperand Reg:53>> ``` This commit fixes this issue by moving expansion of those two opcodes into AVRExpandPseudo. This bug was originally discovered due to the Rust compiler_builtins library. Its 0.1.37 release contained a 128-bit software division/remainder routine that exercised this buggy branch in the code. Reviewed By: benshi001 Differential Revision: https://reviews.llvm.org/D123528
|
cc @nikic |
Patryk27
added a commit
to Patryk27/rust
that referenced
this pull request
May 9, 2022
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 9, 2022
Upgrade llvm-project (rustc + avr = lovelove back again!) See: rust-lang/llvm-project#139 tl;dr: - closes rust-lang#83633, - closes rust-lang#82104, - closes rust-lang#79889, - closes rust-lang/compiler-builtins#400. 🙂
|
I've been using these patches in a custom Rust+LLVM build for a while now, and very happy with it! Glad to see them merged finally; and many thanks @Patryk27 for your efforts ❤️ |
vext01
pushed a commit
to vext01/llvm-project
that referenced
this pull request
Apr 25, 2024
Serialise the successor block of unconditional branches.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This merge request contains two commits cherry-picked from LLVM's main branch that solve the infamous
LLVM ERROR: Not supported instrproblem¹, making rustc able to compile for AVR back again 🙂At the moment people wanting to play with Rust + AVR are being forced to use the, uhm, mature version of
nightly-2021-01-07that doesn't crash withNot supported instr, but contains a multitude of codegen bugs that have been since fixed in LLVM (e.g. rust-lang/rust#79889 should Just Work ™️ now, but people can't really test it if they are still using the older compiler).Checks
I've checked the code by compiling rustc locally and simavr-ing a few examples from https://github.com/Rahix/avr-hal/tree/5d757696e338104622a0f89c51020b718bf48b62/examples/arduino-uno - everything seems to be working correctly.
I'm also developing a bit more complex AVR application (firmware? 🙃) myself, and I haven't noticed any compiler bugs, including when running the code on an actual Atmega328p.
¹ rust-lang/rust#82104, rust-lang/rust#83633