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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
