public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn @ 2015-06-20 11:11 schwab@linux-m68k.org 2015-06-20 11:14 ` [Bug tree-optimization/66612] [6 regression] " schwab@linux-m68k.org ` (6 more replies) 0 siblings, 7 replies; 8+ messages in thread From: schwab@linux-m68k.org @ 2015-06-20 11:11 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org @ 2015-06-20 11:14 ` schwab@linux-m68k.org 2015-06-23 2:33 ` amker at gcc dot gnu.org ` (5 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: schwab@linux-m68k.org @ 2015-06-20 11:14 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org 2015-06-20 11:14 ` [Bug tree-optimization/66612] [6 regression] " schwab@linux-m68k.org @ 2015-06-23 2:33 ` amker at gcc dot gnu.org 2015-07-02 9:22 ` amker at gcc dot gnu.org ` (4 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: amker at gcc dot gnu.org @ 2015-06-23 2:33 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org 2015-06-20 11:14 ` [Bug tree-optimization/66612] [6 regression] " schwab@linux-m68k.org 2015-06-23 2:33 ` amker at gcc dot gnu.org @ 2015-07-02 9:22 ` amker at gcc dot gnu.org 2015-07-02 9:47 ` schwab@linux-m68k.org ` (3 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: amker at gcc dot gnu.org @ 2015-07-02 9:22 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org ` (2 preceding siblings ...) 2015-07-02 9:22 ` amker at gcc dot gnu.org @ 2015-07-02 9:47 ` schwab@linux-m68k.org 2015-07-02 11:00 ` amker at gcc dot gnu.org ` (2 subsequent siblings) 6 siblings, 0 replies; 8+ messages in thread From: schwab@linux-m68k.org @ 2015-07-02 9:47 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org ` (3 preceding siblings ...) 2015-07-02 9:47 ` schwab@linux-m68k.org @ 2015-07-02 11:00 ` amker at gcc dot gnu.org 2015-07-03 2:00 ` amker at gcc dot gnu.org 2015-07-03 3:06 ` amker at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: amker at gcc dot gnu.org @ 2015-07-02 11:00 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org ` (4 preceding siblings ...) 2015-07-02 11:00 ` amker at gcc dot gnu.org @ 2015-07-03 2:00 ` amker at gcc dot gnu.org 2015-07-03 3:06 ` amker at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: amker at gcc dot gnu.org @ 2015-07-03 2:00 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org ` (5 preceding siblings ...) 2015-07-03 2:00 ` amker at gcc dot gnu.org @ 2015-07-03 3:06 ` amker at gcc dot gnu.org 6 siblings, 0 replies; 8+ messages in thread From: amker at gcc dot gnu.org @ 2015-07-03 3:06 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-03 3:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-20 11:11 [Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn schwab@linux-m68k.org 2015-06-20 11:14 ` [Bug tree-optimization/66612] [6 regression] " schwab@linux-m68k.org 2015-06-23 2:33 ` amker at gcc dot gnu.org 2015-07-02 9:22 ` amker at gcc dot gnu.org 2015-07-02 9:47 ` schwab@linux-m68k.org 2015-07-02 11:00 ` amker at gcc dot gnu.org 2015-07-03 2:00 ` amker at gcc dot gnu.org 2015-07-03 3:06 ` amker at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).