Re: Serious code size regression from 3.0.2 to now part two

[tm <tm at mail dot kloo dot net>]

On Fri, 26 Jul 2002, Joern Rennecke wrote:

> tm wrote:
> > 
> > Okay, I've started using -fno-reorder-blocks on my testcase map_fog.i, and
> > the code size is still about 10% worse than 3.0.x.
> > 
> > I think I've tracked this down to really bad branches being generated by
> > gcc. Take a look at this code sequence:
> > 
> >  5124                   .L320:
> >  5125 2a02 4011                 cmp/pz  r0
> >  5126 2a04 8F0C                 bf/s    .L322
> >  5127 2a06 6813                 mov     r1,r8
> >  5128 2a08 9226                 mov.w   .L683,r2
> >  5129 2a0a 3027                 cmp/gt  r2,r0
> >  5130 2a0c 8F09                 bf/s    .L323
> >  5131 2a0e 6103                 mov     r0,r1
> >  5132 2a10 A007                 bra     .L323
> >  5133 2a12 6123                 mov     r2,r1
> >  5134 2a14 00090009             .align 5
> >  5134      00090009
> >  5134      00090009
> >  5135                   .L322:
> >  5136 2a20 E100                 mov     #0,r1
> >  5137                   .L323:
> >  5138 2a22 6013                 mov     r1,r0
> >  5139 2a24 4818                 shll8   r8
> > ..
> > 
> > This is really twisted branch logic.
> 
> It appears the code is geared towards the r0 < 0 case.  Assuming both
> r1 and r0 need to contain the result, optimized code would be:

It appears this code is generated by the front-end.

Here's a dump from the map_fog.i.00.rtl file:



(code_label 38 5174 39 2 "" [0 uses])

(insn 39 38 40 (nil) (set (reg:SI 147 t)
        (geu:SI (reg/v/f:SI 162)
            (reg/v/f:SI 161))) -1 (nil)
    (nil))

(jump_insn 40 39 41 (nil) (set (pc)
        (if_then_else (eq (reg:SI 147 t)
                (const_int 0 [0x0]))
            (label_ref 43)
            (pc))) -1 (nil)
    (nil))

(jump_insn 41 40 42 (nil) (set (pc)
        (label_ref 5181)) -1 (nil)
    (nil))

(barrier 42 41 43)

(code_label 43 42 44 4 "" [0 uses])

(note 44 43 5178 NOTE_INSN_LOOP_END_TOP_COND)

(jump_insn 5178 44 5179 (nil) (set (pc)
        (label_ref 5175)) -1 (nil)
    (nil))

Just for a lark, I decided to check the x86 codegen. The same problem
occurs there:

...
.L310:
        testl   %edi, %edi
        movl    %edx, %esi
        js      .L312
        cmpl    $255, %edi
        movl    %edi, %edx
        jle     .L313
        movl    $255, %edx
        jmp     .L313
        .p2align 4,,7
.L312:
        xorl    %edx, %edx
.L313:
        movl    %edx, %edi
...

As a matter of fact, almost every basic block in the x86 codegen ends in a
jump instruction and almost none of them fall through to the next basic
block:

        jmp     .L7
        .p2align 4,,7
.L6:
        xorl    %eax, %eax
.L7:
...
        jmp     .L10
        .p2align 4,,7
.L9:
        xorl    %edx, %edx
.L10:
...
        jmp     .L13
        .p2align 4,,7
.L12:
        xorl    %edx, %edx
.L13:
        movl    %edx, %edi
...

So it appears something in the front-end is mucking around with branches
and destroying most of the fall-through basic blocks for this testcase.

Toshi