[Bug rtl-optimization/58033] counterproductive bb-reorder

["tejohnson at google dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033

--- Comment #2 from Teresa Johnson <tejohnson at google dot com> ---
On Tue, Jul 30, 2013 at 2:00 PM, olegendo at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58033
>
>             Bug ID: 58033
>            Summary: counterproductive bb-reorder
>            Product: gcc
>            Version: 4.9.0
>             Status: UNCONFIRMED
>           Severity: normal
>           Priority: P3
>          Component: rtl-optimization
>           Assignee: unassigned at gcc dot gnu.org
>           Reporter: olegendo at gcc dot gnu.org
>                 CC: steven at gcc dot gnu.org, tejohnson at google dot com
>             Target: sh*-*-*
>
> On SH, compiling the following code with -O2
>
> #include <bitset>
>
> std::bitset<32> make_bits (void)
> {
>   std::bitset<32> r;
>   for (auto&& i : { 4, 5, 6, 10 })
>     if (i < r.size ())
>       r.set (i);
>
>   return r;
> }
>
> results in the following code:
>
>         mov.l   .L8,r1
>         mov     #0,r0
>         mov     #31,r7
>         mov     #1,r6
>         mov     #4,r2
> .L2:
>         mov.l   @r1,r3
>         cmp/hi  r7,r3
>         bf/s    .L7

I assume it is the above branch that is the issue (not the bf/s .L2
below as that is the same in both versions of the code). I'm assuming
this is not build with FDO? In that case bbro is probably at the mercy
of whatever probabilities the static heuristics assigned to the
branches. Although if it is 50-50 then I'm not sure offhand what
happens - maybe it is biasing in favor of having the shortest trace?
This is a great test case for motivating range propagation. =)

Can you attach the dump created with -fdump-rtl-bbro-all? We can see
what the edge probabilities are. For some reason it is not compiling
for me - what options do you use? My (4_7-based) g++ is complaining
about the "auto":

$ g++ -O2 pr58033.cc -S
pr58033.cc: In function 'std::bitset<32ul> make_bits()':
pr58033.cc:6:12: error: expected unqualified-id before '&&' token
   for (auto&& i : { 4, 5, 6, 10 })

Teresa

>         mov     r6,r5
> .L3:
>         dt      r2
>         bf/s    .L2     // branch if value not > 31, i.e. in each iteration
>         add     #4,r1
>         rts
>         nop
>         .align 1
> .L7:
>         shld    r3,r5
>         bra     .L3
>         or      r5,r0
> .L9:
>         .align 2
> .L8:
>         .long   _._45+0
>
> _._45:
>         .long   4
>         .long   5
>         .long   6
>         .long   10
>
> Disabling the bb-reorder pass or using -Os results in more compact and faster
> code:
>
>         mov.l   .L7,r1
>         mov     #0,r0
>         mov     #31,r7
>         mov     #1,r6
>         mov     #4,r2
> .L2:
>         mov.l   @r1,r3
>         cmp/hi  r7,r3
>         bt/s    .L3    // branch if value > 31, i.e. never.
>         mov     r6,r5
>         shld    r3,r5
>         or      r5,r0
> .L3:
>         dt      r2
>         bf/s    .L2
>         add     #4,r1
>         rts
>         nop
>
> Of course the bb-reorder pass doesn't know that the values in this case are
> always in range.  Still, maybe it could be improved by not splitting out a BB
> if it consists only of a few insns?  I've tried increasing the branch cost but
> it won't do anything.
>
> Teresa, Steven,
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.