This is a small pet peeve from me. This change makes sure the AVR backend uses
the correct private label prefix (.L) so that private labels are hidden in
avr-objdump.
Example code:
define i8 @foo(i1 %cond) {
br i1 %cond, label %then, label %else
then:
ret i8 3
else:
ret i8 5
}
When compiling this:
llc -march=avr -filetype=obj -o test.o test.ll
and then dumping it:
avr-objdump -d test.o
You would previously get an ugly temporary label:
00000000 <foo>:
0: 81 70 andi r24, 0x01 ; 1
2: 80 30 cpi r24, 0x00 ; 0
4: f9 f3 breq .-2 ; 0x4 <foo+0x4>
6: 83 e0 ldi r24, 0x03 ; 3
8: 08 95 ret
0000000a <LBB0_2>:
a: 85 e0 ldi r24, 0x05 ; 5
c: 08 95 ret
This patch fixes that, the output is now:
00000000 <foo>:
0: 81 70 andi r24, 0x01 ; 1
2: 80 30 cpi r24, 0x00 ; 0
4: 01 f0 breq .+0 ; 0x6 <foo+0x6>
6: 83 e0 ldi r24, 0x03 ; 3
8: 08 95 ret
a: 85 e0 ldi r24, 0x05 ; 5
c: 08 95 ret
Note that as you can see the breq operand is different. However it is
still the same after linking:
4: 11 f0 breq .+4
Differential Revision: https://reviews.llvm.org/D75124
This change modifies the LLVM ISel lowering settings so that
8-bit/16-bit multiplication is expanded to calls into the compiler
runtime library if the MCU being targeted does not support
multiplication in hardware.
Before this, MUL instructions would be generated on CPUs like the
ATtiny85, triggering a CPU reset due to an illegal instruction at
runtime.
First raised in https://github.com/avr-rust/rust/issues/124.
llvm-svn: 351523
Once MULHS was expanded, this exposed an issue where the condition
register was thought to be 16-bit. This caused an attempt to copy a
16-bit register to an 8-bit register.
Authored by Jake Goulding
llvm-svn: 283634
Ayke van Laethem