[Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

            Bug ID: 66612
           Summary: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c
                    scan-assembler bdn
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
                CC: amker at gcc dot gnu.org
            Blocks: 62173
  Target Milestone: ---
            Target: powerpc64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/20050830-1.c -O2 -S -m64
-o 20050830-1.s
$ grep -c bdn 20050830-1.s 
0

5fe66b3cf99994fd9c8c68cea43aa1cf42eaa76d is the first bad commit
commit 5fe66b3cf99994fd9c8c68cea43aa1cf42eaa76d
Author: amker <amker@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Jun 2 03:33:35 2015 +0000
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@224009
138bc75d-0d04-0410-961f-82ee72b054a4


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
[Bug 62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0
            Summary|[6 regrssion] FAIL:         |[6 regression] FAIL:
                   |gcc.target/powerpc/20050830 |gcc.target/powerpc/20050830
                   |-1.c scan-assembler bdn     |-1.c scan-assembler bdn

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

--- Comment #1 from amker at gcc dot gnu.org ---
Likely the change causes difference ivo result, and the wanted instruction not
generated.  I shall have a look.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

--- Comment #2 from amker at gcc dot gnu.org ---
Hi,
I had a look of generated assembly.  The old code is as below:
        .file   "20050830-1.c"
        .machine power4
        .section        ".toc","aw"
        .section        ".text"
        .section        ".toc","aw"
.LC0:
        .quad   a
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl foo
        .section        ".opd","aw"
        .align 3
foo:
        .quad   .L.foo,.TOC.@tocbase,0
        .previous
        .type   foo, @function
.L.foo:
        cmpwi 7,3,511
        ble 7,.L4
        lis 9,0xffff
        addis 8,2,.LC0@toc@ha           # gpr load fusion, type long
        ld 8,.LC0@toc@l(8)
        li 10,42
        ori 9,9,0xff00
        rldicl 9,9,0,32
        add 9,3,9
        cmpwi 7,9,256
        addi 9,9,-256
        rldicl 9,9,56,40
        addi 9,9,1
        mtctr 9
        blt- 7,.L9
        .p2align 5,,31
.L3:
        sldi 9,3,2
        addi 3,3,-256
        extsw 3,3
        stwx 10,8,9
        bdnz .L3
.L4:
        li 3,0
        blr
.L9:
        li 9,1
        mtctr 9
        b .L3
        .long 0
        .byte 0,0,0,0,0,0,0,0
        .size   foo,.-.L.foo
        .ident  "GCC: (GNU) 6.0.0 20150602 (experimental)"


And now it is as below
        .file   "20050830-1.c"
        .machine power4
        .section        ".toc","aw"
        .section        ".text"
        .section        ".toc","aw"
.LC1:
        .quad   a
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl foo
        .section        ".opd","aw"
        .align 3
foo:
        .quad   .L.foo,.TOC.@tocbase,0
        .previous
        .type   foo, @function
.L.foo:
        cmpwi 7,3,511
        ble 7,.L4
        addi 9,3,-512
        addis 10,2,.LC1@toc@ha          # gpr load fusion, type long
        ld 10,.LC1@toc@l(10)
        rlwinm 9,9,0,0,23
        subf 9,9,3
        sldi 3,3,2
        sldi 9,9,2
        add 3,3,10
        addi 9,9,-1024
        add 9,9,10
        li 10,42
        .p2align 4,,15
.L3:
        stw 10,0(3)
        addi 3,3,-1024
        cmpld 7,3,9
        bne 7,.L3
.L4:
        li 3,0
        blr
        .long 0
        .byte 0,0,0,0,0,0,0,0
        .size   foo,.-.L.foo
        .ident  "GCC: (GNU) 6.0.0 20150627 (experimental)"

The difference is because IVOPT chooses arrary address IV and use it to
eliminate the old comparison.  That's why the bdn instruction isn't generated.

I am not good in ppc assembly code, but seems to me the code is improved since
there are one fewer instructions in loop now.

BTW, which instruction in old assembly's loop is the store instruction?

Thanks,
bin

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
stwx 10,8,9 -> *(int*)(r8+r9)=r10

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

--- Comment #5 from amker at gcc dot gnu.org ---
Hmm, (In reply to amker from comment #4)
> (In reply to Andreas Schwab from comment #3)
> > stwx 10,8,9 -> *(int*)(r8+r9)=r10
> 
> I am wondering how should we handle this failure.  Create a new doloop test
> and change this one testing the optimization gcc does now?
> 
> Thanks,
> bin

Hmm,
Actually, GCC shouldn't eliminate loop condition with address type candidate. 
Like on 32 bits powerpc, the loop can be further optimized with do-loop
structure:

foo:
        cmpwi 7,3,511
        ble- 7,.L4
        addi 9,3,-256
        lis 10,a@ha
        cmpwi 7,9,256
        addi 9,3,-512
        srwi 9,9,8
        la 10,a@l(10)
        slwi 3,3,2
        addi 9,9,1
        add 3,3,10
        mtctr 9
        li 10,42
        blt- 7,.L9
.L3:
        stw 10,0(3)
        addi 3,3,-1024
        bdnz .L3
.L4:
        li 3,0
        blr
.L9:
        li 9,1
        mtctr 9
        b .L3

Please correct me if I was wrong assuming same scenario on powerpc64 and
powerpc.

Thanks

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

amker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-03
     Ever confirmed|0                           |1

--- Comment #6 from amker at gcc dot gnu.org ---
This relates to cost computation on powerpc64.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612

--- Comment #7 from amker at gcc dot gnu.org ---
On powerpc32, the address candidate doesn't have the period precision to
eliminate conditional iv.  That's why bdn is generated.
On powerpc64, the address candidate does have the period precision because the
address type is of 64bit now.

This reveals a missed-optimization in IVO.  Currently tree level IVO doesn't
know if the loop condition can be tranformed into low-overhead looping
structure (using doloop).  One exception is when the condition is a comparison
of the candidate IV against ZERO (Even in this case, it doesn't know how much
cost could be saved with doloop optimization, it just decrease the cost by a
provisional const).  

As for this case, the loop condition is (w_3(D) > 511), which could be
transformed to a comparison against ZERO in rtl level doloop optimization. 
Unfortunately, tree IVO knows nother about this.  It's also difficult to check
whether doloop is viable on GIMPLE, because there are many heuristics/fallouts
in RTL transformation.  

I consider this as another inconsistency issue between tree IVO and rtl loop
optimizers.  Another example is RTL unroller messes up induction variables
chosen by tree IVO.

I think we could XFAIL this on powerpc64 for now.  So what's your opinions?

Thanks.