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

[Joern Rennecke <joern dot rennecke at superh dot com>]

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:
would be:
 cmpz/pz r0
 mov r1,r8
 bf/s .L322
 mov #0,r1
 mov.w .L683,r2
 mov r0,r1
 cmp/gt r2,r0
 bf L322
 mov r2,r1
L323:
 mov r1,r0
L322:

and of course reorg will always mess up the scheduling of the mov r0,r1.

OTOH, if we want to optimize for the r0 >= 0 case, and we don't need
the result in r1, optimized code would be:

 cmp/pz r0
 mov .L683,r2
 bt L322
 mov #0,r0
L322:
 cmp/gt r2,r0
 bf L323
 mov r2,r0
L323:

obvious problems with getting this code are
- the branch heuristics don't know that a branch-around-a-single-insn is cheap.
- sched2 won't pull the load of r2 above L322
- reorg might feel compelled to do something silly about the branches.

So maybe we should pretend we have conditional instructions, which are
actually simple instructions with a branch around them.
A good first approximation for 'simple' is probably:
(eq_attr "in_delay_slot" "yes")
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330