7 Commits

Author SHA1 Message Date
Ben Shi
2a528760bf [AVR] Fix an issue of writing 16-bit ports
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 https://github.com/llvm/llvm-project/issues/58395

Reviewed By: aykevl, jacquesguan

Differential Revision: https://reviews.llvm.org/D141752
2023-04-17 15:35:33 +08:00
Jay Foad
effb7ab6c2 [TwoAddressInstruction] Improve tests for register killed by instruction
Define and use a MachineOperand overload of isPlainlyKilled. This
improves codegen in a couple of tests because it catches the case where
MO does not kill Reg but another operand of the same instruction does.

Differential Revision: https://reviews.llvm.org/D147167
2023-03-30 19:20:03 +01:00
Ayke van Laethem
9592920890
[AVR] Optimize 32-bit shifts: optimize REG_SEQUENCE
This pseudo-instruction stores two small (8-bit) registers into one wide
(16-bit) register. But apparently the order matters a lot to the
register allocator.
This patch changes the order of inserting the registers to optimize for
the best register allocation in the tests of shift32.ll. It might be
detrimental in other cases, but keeping the registers in the same
physical register seems like it would be a common case.

Differential Revision: https://reviews.llvm.org/D140573
2023-01-08 20:05:31 +01:00
Ayke van Laethem
fad5e0cf50
[AVR] Optimize 32-bit shifts: reverse shift + move
This optimization turns shifts of almost a multiple of 8 into a shift
into the opposite direction. Unfortunately it doesn't compose well with
the other optimizations (I've tried) so it's separate from them.

Differential Revision: https://reviews.llvm.org/D140572
2023-01-08 20:05:31 +01:00
Ayke van Laethem
81f5f22f27
[AVR] Optimize 32-bit shifts: shift by 4 bits
This uses a complicated shift sequence that avr-gcc also uses, but
extended to work over any number of bytes and in both directions
(logical shift left and logical shift right). Unfortunately it can't be
used for an arithmetic shift right: I've tried to come up with a
sequence but couldn't.

Differential Revision: https://reviews.llvm.org/D140571
2023-01-08 20:05:31 +01:00
Ayke van Laethem
8f8afabd32
[AVR] Optimize 32-bit shift: move bytes around
This patch optimizes 32-bit constant shifts by renaming registers. This
is very effective as the compiler would otherwise need to do a lot of
single bit shift instructions. Instead, the registers are renamed at the
SSA level which means the register allocator will insert the necessary
mov instructions.

Unfortunately, the register allocator will insert some unnecessary movs
with the current code. This will be fixed in a later patch.

Differential Revision: https://reviews.llvm.org/D140570
2023-01-08 20:05:31 +01:00
Ayke van Laethem
840d10a1d2
[AVR] Custom lower 32-bit shift instructions
32-bit shift instructions were previously expanded using the default
SelectionDAG expander, which meant it used 16-bit constant shifts and
ORed them together. This works, but is far from optimal.

I've optimized 32-bit shifts on AVR using a custom inserter. This is
done using three new pseudo-instructions that take the upper and lower
bits of the value in two separate 16-bit registers and outputs two
16-bit registers.

This is the first commit in a series. When completed, shift instructions
will take around 31% less instructions on average for constant 32-bit
shifts, and is in all cases equal or better than the old behavior. It
also tends to match or outperform avr-gcc: the only cases where avr-gcc
does better is when it uses a loop to shift, or when the LLVM register
allocator inserts some unnecessary movs. But it even outperforms avr-gcc
in some cases where avr-gcc does not use a loop.

As a side effect, non-constant 32-bit shifts also become more efficient.

For some real-world differences: the build of compiler-rt I use in
TinyGo becomes 2.7% smaller and the build of picolibc I use becomes 0.9%
smaller. I think picolibc is a better representation of real-world code,
but even a ~1% reduction in code size is really significant.

The current patch just lays the groundwork. The result is actually a
regression in code size. Later patches will use this as a basis to
optimize these shift instructions.

Differential Revision: https://reviews.llvm.org/D140569
2023-01-08 20:05:31 +01:00