[avr-gcc-list] Improving bit manipulations in avr-gcc 4.x

[Georg-Johann Lay]

Hi,

evaluating avr-gcc 4.3.2 I observed some weaknesses concerning the
code it generates. One example is this:

<pre>
unsigned char extract_sfrbit_1()
{
    unsigned char i = 0;

    if (REG & 64) i = 1;

    return i;
}
</pre>

which is compiled (-Os) to

<pre>
extract_sfrbit_1:
        in r24,32-0x20   ;  6   *movqi/4        [length = 1]
        ldi r25,lo8(0)   ;  26  *movqi/2        [length = 1]
        ldi r18,6        ;  31  *lshrhi3_const/5        [length = 5]
1:      lsr r25
        ror r24
        dec r18
        brne 1b
        andi r24,lo8(1)  ;  14  andqi3/2        [length = 1]
        ret      ;  29  return  [length = 1]
</pre>

The Middleend flatens control flow by replacing some conditionals with
algebraic manipulations. However, jumps on AVR are not as expensive as 
on 32 bit machines while shifts are more expensive.
But even in backends like avr is is easier to
transform algebraic stuff into jumps than the other way round.

Problems like this can be fixed by introducing some patterns for the
combiner. I implemented some patters which deal with bit
manipulations. Overall, the code is faster and smaller, but some
problems arise:

1) Would these pattern be helpful to improve gcc?
2) I never contributed to gcc, so I am unsure how to do that.
3) What about testing? I have no test environment.
4) The patch is just intended to be a snapshot. 
   The "-mtest" is used for testing purposes and to see if code size
   reduces or not.
5) The pattern themselves work fine. 
   However, avr.c:adjust_insn_length() makes many assumptions on
   patterns and how they look like or don't look like.
   This is very hard to maintain for komplex patterns, and also it is
   error prone. Therefore, I did not (yet) implement the new stuff
   on the adjust_insn_length-level. Is there a more convenient, less
   error prone and more readable way to state insn lengths? Like,
   e.g. to assign negative insn length to indicate that an alternative's
   length needs adjustment?

Please be kind, I am a newbie :-)

Consider the attached patch just as a basis for a talk.
The C source can be used to make gcc to use most of the new patterns.

The diff is against gcc_4_3_2_release. 
And again: This patch may lead to wrong code because insn lengths might be
overwritten by adjust_insn_length()

Georg-Johann

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

bit1.patch
Description: Text Data

input-bit1.c
Description: Text document