Cherry-pick improvements for AVR codegen #149
Closed
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 patch fixes the inaccurate decoding of the offset operand of the conditional branch instructions. Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D140816
The functionality of FeaturePROGMEM is all equivalant to FeatureLPM. Reviewed By: Chenbing.Zheng, aykevl Differential Revision: https://reviews.llvm.org/D141242
Reviewed By: Chenbing.Zheng, aykevl Differential Revision: https://reviews.llvm.org/D142170
Fixes llvm#30923 Reviewed By: jacquesguan, aykevl Differential Revision: https://reviews.llvm.org/D142281
In avr-gcc, the destination of "rjmp label + offset" is address 'label + offset', while destination of "rjmp . + offset" is 'address_of_rjmp + offset + 2'. Clang is in accordance with avr-gcc for "rjmp label + offset", but emits incorrect destination of "rjmp . + offset" to 'address_of_rjmp + offset', in which the expected offset 2 is missing. This patch fixes the above issue. Fixes llvm#60019 Reviewed By: jacquesguan, aykevl Differential Revision: https://reviews.llvm.org/D143901
This is in accordance with avr-gcc, even '-mno-relax' is specified to avr-gcc, this flag will also be added to the output relocatables. With this flag set, the GNU ld will perform long call -> short call optimization for AVR, otherwise not. Fixes llvm#54508 Reviewed By: MaskRay, jacquesguan, aykevl Differential Revision: https://reviews.llvm.org/D144617
In AVRFrameLowering::spillCalleeSavedRegisters(), when a 16-bit livein register is spilled, two PUSH instructions are generated for the higher and lower 8-bit registers. But these two 8-bit registers are marked as killed in the two PUSH instructions, so any future use of them will cause a crash. This patch fixes the above issue by adding the two sub 8-bit registers to the livein list. Fixes llvm#56423 Reviewed By: jacquesguan Differential Revision: https://reviews.llvm.org/D144720
The 'ELPM' instruction has three forms: -------------------------- | form | feature | | ----------- | -------- | | ELPM | hasELPM | | ELPM Rd, Z | hasELPMX | | ELPM Rd, Z+ | hasELPMX | -------------------------- The second form is always used in the expansion of the pseudo instruction 'ELPMBRdZ'. But for devices without ELPMX but only with ELPM, only the first form can be emitted. Reviewed By: jacquesguan Differential Revision: https://reviews.llvm.org/D141221
The 'LPM' instruction has three forms: ------------------------ | form | feature | | ---------- | --------| | LPM | hasLPM | | LPM Rd, Z | hasLPMX | | LPM Rd, Z+ | hasLPMX | ------------------------ The second form is always selected in ISelDAGToDAG, even on devices without FeatureLPMX. This patch emits "LPM + MOV" on devices with only FeatureLPM. Reviewed By: jacquesguan Differential Revision: https://reviews.llvm.org/D141246
The 'ELPM' instruction has three forms: -------------------------- | form | feature | | ----------- | -------- | | ELPM | hasELPM | | ELPM Rd, Z | hasELPMX | | ELPM Rd, Z+ | hasELPMX | -------------------------- The second form is always used in the expansion of pseudo instructions LPMWRdZ/ELPMWRdZ. But for devices without ELPMX and with only ELPM, only the first form can be used. Reviewed By: aykevl, Miss_Grape Differential Revision: https://reviews.llvm.org/D141264
We should reject "ldd Rn, X" with explicit error message rather than "llvm_unreachable" in llvm's release build. Fixes llvm#62012 Reviewed By: Miss_Grape Differential Revision: https://reviews.llvm.org/D147877
We temporarily only allow post increment load/store from/to data memory, and disable post increment load from program space. Updates llvm#59914 Reviewed By: mzh Differential Revision: https://reviews.llvm.org/D147761
For 16-bit ports, the normal devices reqiure writing high byte first and then low byte. But the XMEGA devices require the reverse order. Fixes llvm#58395 Reviewed By: aykevl, jacquesguan Differential Revision: https://reviews.llvm.org/D141752
Fixes llvm#63098 Reviewed by: benshi001 Differential Revision: https://reviews.llvm.org/D152063
Reviewed By: aykevl, Patryk27 Differential Revision: https://reviews.llvm.org/D152087
Reviewed By: Patryk27, jacquesguan Differential Revision: https://reviews.llvm.org/D152129
Reviewed By: Patryk27 Differential Revision: https://reviews.llvm.org/D152605
Reviewed By: Patryk27 Differential Revision: https://reviews.llvm.org/D152606
Since ROLBRd needs an implicit R1 (on AVR) or an implicit R17 (on AVRTiny), we split ROLBRd to ROLBRdR1 (on AVR) and ROLBRdR17 (on AVRTiny). Reviewed By: aykevl, Patryk27 Differential Revision: https://reviews.llvm.org/D152248
Fixes llvm#63100 Reviewed By: aykevl, Patryk27, jacquesguan Differential Revision: https://reviews.llvm.org/D152130
Fixes llvm#63100 Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D152365
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
|
cc @nikic |
|
LLVM 17 will branch tomorrow, and we'll likely start the Rust rebase soon after. If you can wait for that to land (which admittedly sometimes takes a while to iron out), then I think that would be better than taking a ton of backports. |
|
Oh sure, even better 🙂 |
This was referenced Jul 25, 2023
vext01
pushed a commit
to vext01/llvm-project
that referenced
this pull request
May 2, 2024
Tidy up "patch-up" logic.
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.
Solves:
<<doesn't work correctly on >= 32-bit integers on a 16-bit platform rust#82380I've simply cherry-picked (almost) all AVR-related commits that have been committed since the latest LLVM bump here.
I've tested this merge request by compiling LLVM locally and trying out a few programs (e.g. a Mandelbrot fractal printer) through
simavr- everything seems to be in order.