gcc for m68332 isn't using bset and bclr

[Petter Reinholdtsen <pere at hungry dot com>]

I'm using GCC 2.95.2 as a cross compiler for the m68332 micro
controller.

The compiler does not seem to use the bset and bclr instructions
available on the processor.  The following test program should
demonstrate the problem.

  #if 0
  #define CLEAR_BIT(a, b)  __asm volatile ("bclr.b %0, %1" : : "I"(b), "m" (a))
  #define SET_BIT(a, b)    __asm volatile ("bset.b %0, %1" : : "I"(b), "m" (a))
  #else
  #define CLEAR_BIT(a, b)  ((a) &= ~ (1<<(b)))
  #define SET_BIT(a, b)    ((a) |=   (1<<(b)))
  #endif

  int
  main(int argc, char *argv[])
  {
    volatile int separator = argc;
    volatile unsigned char *ParPortData = (unsigned char*)0x00e01800;
    CLEAR_BIT(*ParPortData, 1);
    separator *= 10;
    SET_BIT(*ParPortData, 1);
    return separator;
  }

This is a stripped down version of our parport communication code.  I
compile the program with the following parameters:

  m68k-coff-gcc -B /user/res/uwarobot/g++-m68k/lib/gcc-lib/m68k-coff/2.95.2/ \
    -O6 -fomit-frame-pointer -fstrength-reduce -fexpensive-optimizations \
    -fmove-all-movables -I../../mc/include -I../../mc/libc/include -Wall \
    -pedantic -ansi -msoft-float -m68332 -c -S test.c

I compile two version of the program, one with #if 0 and the other
with #if 1, and diff the resulting assembly code:

  --- test0.s    Thu Mar  2 12:46:08 2000
  +++ test1.s    Thu Mar  2 12:40:21 2000
  @@ -11,17 +11,17 @@
        jsr __main
        move.l %d2,4(%sp)
        move.l #14686208,%a1
  -     move.b (%a1),%d0
  -     and.b #253,%d0
  -     move.b %d0,(%a1)
  +#APP
  +     bclr.b #1, (%a1)
  +#NO_APP
        move.l 4(%sp),%a0
        lea (%a0,%a0.l*4),%a0
        move.l %a0,%d0
        add.l %d0,%d0
        move.l %d0,4(%sp)
  -     move.b (%a1),%d0
  -     or.b #2,%d0
  -     move.b %d0,(%a1)
  +#APP
  +     bset.b #1, (%a1)
  +#NO_APP
        move.l 4(%sp),%d0
        move.l (%sp)+,%d2
        addq.w #8,%sp

As you can see, the C optimized code gives three instructions where
only one would do.  Why is this?  Doesn't gcc know about the bset/bclr
operations on m68332?  If so, how can I fix it?

Happy hacking,
-- 
##>  Petter Reinholdtsen <##    | pere@td.org.uit.no
 O-  <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/    | Go Mozilla, go! Go!