Delay slot filling - what still matters, and what doesn't matter so much anymore?

[Steven Bosscher]

On Sun, Apr 21, 2013 at 11:50 PM, Jeff Law <law@redhat.com> wrote:
> The 60% number also tells me there'd be a lot to be gained by using the
> scheduler's dependency information to drive filling.  We'd end up looking at
> far fewer insns.

FWIW I haven't had much time to hack my sched-dbr.c much, but attached
is the latest copy of it. Stats on my collection of cc1-i files:

$ for d in nodelay/ reorg/ dbr/ ; do grep -w nop ${d}/* | wc ; done
 383532  767091 10550413
 164616  329259 4185216
 179938  359903 4217429

where nodelay is -fno-delayed-branch, reorg is current reorg.c but
with annulling disabled, and dbr is this sched-dbr.c.

It's obviously far from complete, it's not even in "toy" maturity :-)
For one thing, annulling branches are not handled at all yet. Other
things where it fails:

* memory ops in call delay slots:
@@ -7414,8 +7402,9 @@
        ldx     [%l4+%lo(valvar_pool)], %o0
 .L:
        stx     %g1, [%fp+2039]
+       stx     %g2, [%fp+2031]
        call    pool_alloc, 0
-        stx    %g2, [%fp+2031]
+        nop
        stb     %g0, [%o0+12]
        stx     %i4, [%o0]
        ldx     [%fp+2031], %g2
...
@@ -7579,8 +7567,9 @@
        ldx     [%fp+2039], %o1
        call    htab_find_with_hash, 0
         srl    %o2, 0, %o2
+       stx     %o0, [%fp+2031]
        brz,pn  %o0, .L
-        stx    %o0, [%fp+2031]
+        nop
 .L:
        ldx     [%fp+2039], %g1
        brz,pn  %g1, .L


* funny things with returns that look wrong to me but haven't had time
to look into:
@@ -7950,9 +7939,8 @@
        ldx     [%i3], %o1
        ldx     [%g4+32], %o0
        call    notify_dependents_of_resolved_value.isra.46, 0
-        mov    %l7, %i0
-       return  %i7+8
-        nop
+        jmp    %i7+8
+        restore %g0, %l7, %o0
 .L:
        ldx     [%fp+2039], %g2
        ldx     [%g2+8], %g1

* picking insns from after the delay insn:
@@ -18,9 +18,9 @@
        sra     %i5, 0, %g1
        add     %g1, 2, %g1
        sllx    %g1, 3, %g1
-       ldx     [%i4+%g1], %g1
        call    %g1, 0
-        add    %i5, -1, %i5
+        ldx    [%i4+%g1], %g1
+       add     %i5, -1, %i5
        cmp     %i5, -1
        bne,pt  %icc, .L
         nop


OTOH it also already successfully finds opportunities that reorg.c
doesn't see, e.g.:

sub    %i4, %i5, %i3             sub     %i4, %i5, %i3
mov    %o0, %i1                  mov     %o0, %i1
sub    %i2, %i3, %i5         <
call   bar, 0                    call    bar, 0
 mov    %i3, %o0                  mov    %i3, %o0
ba,pt  %xcc, .L6             |   ba,pt   %xcc, .L2
 cmp    %i4, %i2             |    sub    %i2, %i3, %i5

reorg.c takes the cmp from the target but sched-dbr looks through the
call to find the sub.

Ciao!
Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sched-dbr.c
Type: text/x-csrc
Size: 12305 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20130422/62381a90/attachment.bin>