86a60e7f1e
Ever since 6859685a87ad093d60c8bed60b116143c0a684c7 (or, precisely, 84428dafc0941e3a31303fa1b286835ab2b8e234) relative jumps emitted by the AVR codegen are off by two bytes - this pull request fixes it. ## Abstract As compared to absolute jumps, relative jumps - such as rjmp, rcall or brsh - have an implied `pc+2` behavior; that is, `jmp 100` is `pc = 100`, but `rjmp 100` gets understood as `pc = pc + 100 + 2`. This is not reflected in the AVR codegen:f95026dbf6/llvm/lib/Target/AVR/MCTargetDesc/AVRAsmBackend.cpp (L89)... which always emits relative jumps that are two bytes too far - or rather it _would_ emit such jumps if not for this check:f95026dbf6/llvm/lib/Target/AVR/MCTargetDesc/AVRAsmBackend.cpp (L517)... which causes most of the relative jumps to be actually resolved late, by the linker, which applies the offsetting logic on its own, hiding the issue within LLVM. [Some time ago](697a162fa6) we've had a similar "jumps are off" problem that got solved by touching `shouldForceRelocation()`, but I think that has worked only by accident. It's exploited the fact that absolute vs relative jumps in the parsed assembly can be distinguished through a "side channel" check relying on the existence of labels (i.e. absolute jumps happen to named labels, but relative jumps are anonymous, so to say). This was an alright idea back then, but it got broken by 6859685a87ad093d60c8bed60b116143c0a684c7. I propose a different approach: - when emitting relative jumps, offset them by `-2` (well, `-1`, strictly speaking, because those instructions rely on right-shifted offset), - when parsing relative jumps, treat `.` as `+2` and read `rjmp .+1234` as `rjmp (1234 + 2)`. This approach seems to be sound and now we generate the same assembly as avr-gcc, which can be confirmed with: ```cpp // avr-gcc test.c -O3 && avr-objdump -d a.out int main() { asm( " foo:\n\t" " rjmp .+2\n\t" " rjmp .-2\n\t" " rjmp foo\n\t" " rjmp .+8\n\t" " rjmp end\n\t" " rjmp .+0\n\t" " end:\n\t" " rjmp .-4\n\t" " rjmp .-6\n\t" " x:\n\t" " rjmp x\n\t" " .short 0xc00f\n\t" ); } ``` avr-gcc is also how I got the opcodes for all new tests like `inst-brbc.s`, so we should be good.
26 lines
506 B
LLVM
26 lines
506 B
LLVM
; RUN: llc -filetype=obj -mtriple=avr < %s | llvm-objdump -dr --no-show-raw-insn - | FileCheck %s
|
|
|
|
define i8 @foo(i8 %a) {
|
|
bb0:
|
|
%0 = tail call i8 @bar(i8 %a)
|
|
%1 = icmp eq i8 %0, 123
|
|
br i1 %1, label %bb1, label %bb2
|
|
|
|
bb1:
|
|
ret i8 100
|
|
|
|
bb2:
|
|
ret i8 200
|
|
}
|
|
|
|
declare i8 @bar(i8);
|
|
|
|
; CHECK: rcall .-2
|
|
; CHECK-NEXT: 00000000: R_AVR_13_PCREL bar
|
|
; CHECK-NEXT: cpi r24, 0x7b
|
|
; CHECK-NEXT: brne .+4
|
|
; CHECK-NEXT: ldi r24, 0x64
|
|
; CHECK-NEXT: ret
|
|
; CHECK-NEXT: ldi r24, 0xc8
|
|
; CHECK-NEXT: ret
|