Re: ARM conditional instruction optimisation bug (feature?)

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On 7/30/09, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On 7/30/09, Zoltán Kócsi <zoltan@bendor.com.au> wrote:
> > On the ARM every instruction can be executed conditionally. GCC very
> > cleverly uses this feature:
> >
> > int bar ( int x, int a, int b )
> > {
> >   if ( x )
> >
> >      return a;
> >    else
> >      return b;
> > }
> >
> > compiles to:
> >
> > bar:
> >        cmp     r0, #0          // test x
> >        movne   r0, r1          // retval = 'a' if !0 ('ne')
> >        moveq   r0, r2          // retval = 'b' if 0 ('eq')
> >        bx      lr
> >
> > However, the following function:
> >
> > extern unsigned array[ 128 ];
> >
> > int     foo( int x )
> > {
> >   int     y;
> >
> >   y = array[ x & 127 ];
> >
> >   if ( x & 128 )
> >
> >      y = 123456789 & ( y >> 2 );
> >   else
> >      y = 123456789 & y;
> >
> >   return y;
> > }
> >
> > compiled with gcc 4.4.0, using -Os generates this:
> >
> > foo:
> >
> >        ldr     r3, .L8
> >        tst     r0, #128
> >        and     r0, r0, #127
> >        ldr     r3, [r3, r0, asl #2]
> >        ldrne   r0, .L8+4            ***
> >        ldreq   r0, .L8+4            ***
> >        movne   r3, r3, asr #2
> >        andne   r0, r3, r0           ***
> >        andeq   r0, r3, r0           ***
> >        bx      lr
> > .L8:
> >        .word   array
> >        .word   123456789
> >
> > The lines marked with the *** -s do the same, one executing if the
> > condition is one way, the other if the condition is the opposite.
> > That is, together they perform one unconditional instruction, except
> > that they use two instuctions (and clocks) instead of one.
> >
> > Compiling with -O2 makes things even worse, because an other issue hits:
> > gcc sometimes changes a "load constant" to a "generate the constant on
> > the fly" even when the latter is both slower and larger, other times it
> > chooses to load a constant even when it can easily (and more cheaply)
> > generate it from already available values. In this particular case it
> > decides to build the constant from pieces and combines that with
> > the generate an unconditional instruction using two complementary
> > conditional instructions method, resulting in this:
> >
> > foo:
> >        ldr     r3, .L8
> >        tst     r0, #128
> >        and     r0, r0, #127
> >        ldr     r0, [r3, r0, asl #2]
> >        movne   r0, r0, asr #2
> >        bicne   r0, r0, #-134217728
> >        biceq   r0, r0, #-134217728
> >        bicne   r0, r0, #10747904
> >        biceq   r0, r0, #10747904
> >        bicne   r0, r0, #12992
> >        biceq   r0, r0, #12992
> >        bicne   r0, r0, #42
> >        biceq   r0, r0, #42
> >        bx      lr
> > .L8:
> >        .word   array
> >
> > Should I report a bug?
>
> This looks like my bug PR21803 (gcc.gnu.org/PR21803). Can you check if
> the ce3 pass creates this code? (Compile with -fdump-rtl-all and look
> at the .ce3 dump and one dump before to see if the .ce3 pass created
> your funny sequence.)
>
> If your problem is indeed caused by the ce3 pass, you should add your
> problem to PR21803, change the "Component" field to "middle-end", and
> adjust the bug summary to make it clear that this is not ia64
> specific.

Oh, and you may also want to try my patch "crossjump_abstract.diff" in
PR20070, it solves problems like yours sometimes (if the sequence is
just right) by crossjumping earlier.

Ciao!
Steven