avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Logical operation improvements


From: Andrew Hutchinson
Subject: [avr-gcc-list] Logical operation improvements
Date: Wed, 09 Jan 2008 22:38:49 -0500
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)



GCC 4.0 introduced a register lowering pass that changes operations on
registers to the the lowest size required by the target (AVR) backend .
For example,  16 bit value that only has lower 8bits used should
(ideally) get lowered to just 8 bit operations .

This is potentially very significant to the AVR since "c" promotion
rules often create 16 bit values from 8 bit values. So lowering should
save registers and instructions! Indeed the effects of the lowering pass
do show up in the code. However, there a few places where the AVR back
end presents gcc with pseudo 16 and 32 bit instructions - which then
inhibits the lowering.

I looked at some of these to see what might be improved.

Firstly, I didn't consider playing with any of the arithmetic
add/sub/compare instructions - since coping with 8 bit carry's does not
seem immediately productive!

The AVR back end contains optimized assembler patterns for the 16/32
bit addition of sign/zero extended 8bit values.  Breaking up the
extension patterns into 8 bit operations  is easy and gives some savings
- but we then loose on the missed arithmetic optimizations (dang it!)

Much clearer was the logical AND/OR/XOR patterns for 16 and 32 bit
operands. These have no carry to worry about . Removing these patterns
forces gcc to use default built in expansion - which are byte
operations. So a 16 bit "AND" turns into 2 x 8 but ANDS
This change produces slightly worse code.

The culprit being the optimised bit test and jump  SBRS/SBIC bit
patterns -  which no longer matched as well. So instead I wrote my own
16/32 bit split patterns - except I  delay the splitting until after
register allocation and reload - which allows any SBRS/SBIC optimization
to work first.

This produced a 0.25% saving on code size of my test program - (which is
AVR butterfly code. ). No areas of worse performance were found.

T am going to look further at  the SBRS/SBIC patterns. One reason being
to avoid the need to "delay" the lowering of logical patterns. If this
can be done, then the splitting of the logical patterns will yield more
savings

The other reason is to recognise more situations  where SBRS and SBIC
can be used to jump over a single instruction. At present they only jump
over single word instructions. So ahead of CALL, LDS,STS and LDI  they
create an unnecessary jump. Which happens surprisingly often.

Andy












reply via email to

[Prev in Thread] Current Thread [Next in Thread]