Re: [PATCH 4/N] Recover GOTO predictor.
This patch breaks bootstrap on AIX and probably is a hidden bug on all targets. With the patch, libbacktrace/xcoff.c fails to compile with the error: /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c: In function 'xcoff_add': /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:822:13: error: 'incl' may be used uninitialized in this function [-Werror=maybe-uninitialized] filename = incl->filename; ~^~~~ /nasfarm/edelsohn/src/src/libbacktrace/xcoff.c:777:22: note: 'incl' was declared here struct xcoff_incl *incl; ^~~~ incl is used immediately above the line that produces the warning -- with no warning. I can provide a pre-processed xcoff.c, if you need it. Thanks, David
Re: [PATCH 4/N] Recover GOTO predictor.
On Mon, Jul 31, 2017 at 9:46 AM, Martin Liškawrote: > Richi? 4 is fine. > Thanks > > On 06/30/2017 03:48 PM, Martin Liška wrote: >> On 06/22/2017 12:27 PM, Richard Biener wrote: >>> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: Hello. There's one additional predictor enhancement that is GOTO predict that used to working. Following patch adds expect statement for C and C++ family languages. There's one fallout which is vrp24.c test-case, where only 'Simplified relational' appears just once. Adding Richi and Patrick who can probably help how to fix the test-case. >>> >>> Happens to be optimized better now, there's only one predicate to simplify >>> left in the IL input to VRP1. I suggest to change it to match 1 times and >>> add >>> -fdump-tree-optimized to dg-options and >>> >>> /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ >>> >>> to verify we have 3 conditions left. >> >> One small note, I see 4 conditions in optimized dump: >> >> sss (struct rtx_def * insn, int code1, int code2, int code3) >> { >> int D1544; >> struct rtx_def * body; >> _Bool D1562; >> >>[100.00%] [count: INV]: >> body_5 = insn_4(D)->u.fld[5].rt_rtx; >> D1544_6 = body_5->code; >> if (D1544_6 == 55) >> goto (L7); [34.00%] [count: INV] >> else >> goto ; [66.00%] [count: INV] >> >>[66.00%] [count: INV]: >> if (code3_7(D) == 99) >> goto ; [34.00%] [count: INV] >> else >> goto (L16); [66.00%] [count: INV] >> >>[22.44%] [count: INV]: >> D1562_9 = code1_8(D) == 10; >> if (D1562_9 == 1) >> goto (L7); [64.00%] [count: INV] >> else >> goto (L16); [36.00%] [count: INV] >> >>[9.82%] [count: INV]: >> arf (); >> >>[46.68%] [count: INV]: >> frob (); [tail call] >> goto (L16); [100.00%] [count: INV] >> >> L7 [48.36%] [count: INV]: >> if (code2_12(D) == 42) >> goto ; [20.24%] [count: INV] >> else >> goto ; [79.76%] [count: INV] >> >> L16 [100.00%] [count: INV]: >> return; >> >> } >> >> Is it a problem or adjusting to 4 is fine? >> >> Martin >> >>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >> >
Re: [PATCH 4/N] Recover GOTO predictor.
Richi? Thanks On 06/30/2017 03:48 PM, Martin Liška wrote: > On 06/22/2017 12:27 PM, Richard Biener wrote: >> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liškawrote: >>> Hello. >>> >>> There's one additional predictor enhancement that is GOTO predict that >>> used to working. Following patch adds expect statement for C and C++ family >>> languages. >>> >>> There's one fallout which is vrp24.c test-case, where only 'Simplified >>> relational' >>> appears just once. Adding Richi and Patrick who can probably help how to >>> fix the >>> test-case. >> >> Happens to be optimized better now, there's only one predicate to simplify >> left in the IL input to VRP1. I suggest to change it to match 1 times and >> add >> -fdump-tree-optimized to dg-options and >> >> /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ >> >> to verify we have 3 conditions left. > > One small note, I see 4 conditions in optimized dump: > > sss (struct rtx_def * insn, int code1, int code2, int code3) > { > int D1544; > struct rtx_def * body; > _Bool D1562; > >[100.00%] [count: INV]: > body_5 = insn_4(D)->u.fld[5].rt_rtx; > D1544_6 = body_5->code; > if (D1544_6 == 55) > goto (L7); [34.00%] [count: INV] > else > goto ; [66.00%] [count: INV] > >[66.00%] [count: INV]: > if (code3_7(D) == 99) > goto ; [34.00%] [count: INV] > else > goto (L16); [66.00%] [count: INV] > >[22.44%] [count: INV]: > D1562_9 = code1_8(D) == 10; > if (D1562_9 == 1) > goto (L7); [64.00%] [count: INV] > else > goto (L16); [36.00%] [count: INV] > >[9.82%] [count: INV]: > arf (); > >[46.68%] [count: INV]: > frob (); [tail call] > goto (L16); [100.00%] [count: INV] > > L7 [48.36%] [count: INV]: > if (code2_12(D) == 42) > goto ; [20.24%] [count: INV] > else > goto ; [79.76%] [count: INV] > > L16 [100.00%] [count: INV]: > return; > > } > > Is it a problem or adjusting to 4 is fine? > > Martin > >> >>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >>> >>> Ready to be installed? >>> Martin >
Re: [PATCH 4/N] Recover GOTO predictor.
On 06/22/2017 12:27 PM, Richard Biener wrote: > On Wed, Jun 21, 2017 at 3:06 PM, Martin Liškawrote: >> Hello. >> >> There's one additional predictor enhancement that is GOTO predict that >> used to working. Following patch adds expect statement for C and C++ family >> languages. >> >> There's one fallout which is vrp24.c test-case, where only 'Simplified >> relational' >> appears just once. Adding Richi and Patrick who can probably help how to fix >> the >> test-case. > > Happens to be optimized better now, there's only one predicate to simplify > left in the IL input to VRP1. I suggest to change it to match 1 times and add > -fdump-tree-optimized to dg-options and > > /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ > > to verify we have 3 conditions left. One small note, I see 4 conditions in optimized dump: sss (struct rtx_def * insn, int code1, int code2, int code3) { int D1544; struct rtx_def * body; _Bool D1562; [100.00%] [count: INV]: body_5 = insn_4(D)->u.fld[5].rt_rtx; D1544_6 = body_5->code; if (D1544_6 == 55) goto (L7); [34.00%] [count: INV] else goto ; [66.00%] [count: INV] [66.00%] [count: INV]: if (code3_7(D) == 99) goto ; [34.00%] [count: INV] else goto (L16); [66.00%] [count: INV] [22.44%] [count: INV]: D1562_9 = code1_8(D) == 10; if (D1562_9 == 1) goto (L7); [64.00%] [count: INV] else goto (L16); [36.00%] [count: INV] [9.82%] [count: INV]: arf (); [46.68%] [count: INV]: frob (); [tail call] goto (L16); [100.00%] [count: INV] L7 [48.36%] [count: INV]: if (code2_12(D) == 42) goto ; [20.24%] [count: INV] else goto ; [79.76%] [count: INV] L16 [100.00%] [count: INV]: return; } Is it a problem or adjusting to 4 is fine? Martin > >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >> >> Ready to be installed? >> Martin
Re: [PATCH 4/N] Recover GOTO predictor.
> PING^1 > > Can you please Honza give a formal approval for the patch? OK, thanks! Honza > > Thanks, > Martin > > On 06/22/2017 01:47 PM, Richard Biener wrote: > > On Thu, Jun 22, 2017 at 12:57 PM, Martin Liškawrote: > >> On 06/22/2017 12:27 PM, Richard Biener wrote: > >>> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: > Hello. > > There's one additional predictor enhancement that is GOTO predict that > used to working. Following patch adds expect statement for C and C++ > family > languages. > > There's one fallout which is vrp24.c test-case, where only 'Simplified > relational' > appears just once. Adding Richi and Patrick who can probably help how to > fix the > test-case. > >>> > >>> Happens to be optimized better now, there's only one predicate to simplify > >>> left in the IL input to VRP1. I suggest to change it to match 1 times > >>> and add > >>> -fdump-tree-optimized to dg-options and > >>> > >>> /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ > >>> > >>> to verify we have 3 conditions left. > >> > >> Thanks for help. > >> What about the comment: > >> > >> /* The first n_sets > 0 test can be simplfiied into n_sets == 1 since > >>n_sets can only have the values [0, 1] as it's the result of a > >>boolean operation. > >> > >>The second n_sets > 0 test can also be simplified into n_sets == 1 > >>as the only way to reach the tests is when n_sets <= 1 and the only > >>value which satisfies both conditions is n_sets == 1. */ > >> > >> I guess just only one can be valid? Or is it a different story now? > > > > The 2nd one is handled by earlier jump-threading. > > > >> Martin > >> > >>> > Patch can bootstrap on ppc64le-redhat-linux and survives regression > tests. > > Ready to be installed? > Martin > >>
Re: [PATCH 4/N] Recover GOTO predictor.
PING^1 Can you please Honza give a formal approval for the patch? Thanks, Martin On 06/22/2017 01:47 PM, Richard Biener wrote: > On Thu, Jun 22, 2017 at 12:57 PM, Martin Liškawrote: >> On 06/22/2017 12:27 PM, Richard Biener wrote: >>> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: Hello. There's one additional predictor enhancement that is GOTO predict that used to working. Following patch adds expect statement for C and C++ family languages. There's one fallout which is vrp24.c test-case, where only 'Simplified relational' appears just once. Adding Richi and Patrick who can probably help how to fix the test-case. >>> >>> Happens to be optimized better now, there's only one predicate to simplify >>> left in the IL input to VRP1. I suggest to change it to match 1 times and >>> add >>> -fdump-tree-optimized to dg-options and >>> >>> /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ >>> >>> to verify we have 3 conditions left. >> >> Thanks for help. >> What about the comment: >> >> /* The first n_sets > 0 test can be simplfiied into n_sets == 1 since >>n_sets can only have the values [0, 1] as it's the result of a >>boolean operation. >> >>The second n_sets > 0 test can also be simplified into n_sets == 1 >>as the only way to reach the tests is when n_sets <= 1 and the only >>value which satisfies both conditions is n_sets == 1. */ >> >> I guess just only one can be valid? Or is it a different story now? > > The 2nd one is handled by earlier jump-threading. > >> Martin >> >>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >>
Re: [PATCH 4/N] Recover GOTO predictor.
On Thu, Jun 22, 2017 at 12:57 PM, Martin Liškawrote: > On 06/22/2017 12:27 PM, Richard Biener wrote: >> On Wed, Jun 21, 2017 at 3:06 PM, Martin Liška wrote: >>> Hello. >>> >>> There's one additional predictor enhancement that is GOTO predict that >>> used to working. Following patch adds expect statement for C and C++ family >>> languages. >>> >>> There's one fallout which is vrp24.c test-case, where only 'Simplified >>> relational' >>> appears just once. Adding Richi and Patrick who can probably help how to >>> fix the >>> test-case. >> >> Happens to be optimized better now, there's only one predicate to simplify >> left in the IL input to VRP1. I suggest to change it to match 1 times and >> add >> -fdump-tree-optimized to dg-options and >> >> /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ >> >> to verify we have 3 conditions left. > > Thanks for help. > What about the comment: > > /* The first n_sets > 0 test can be simplfiied into n_sets == 1 since >n_sets can only have the values [0, 1] as it's the result of a >boolean operation. > >The second n_sets > 0 test can also be simplified into n_sets == 1 >as the only way to reach the tests is when n_sets <= 1 and the only >value which satisfies both conditions is n_sets == 1. */ > > I guess just only one can be valid? Or is it a different story now? The 2nd one is handled by earlier jump-threading. > Martin > >> >>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >>> >>> Ready to be installed? >>> Martin >
Re: [PATCH 4/N] Recover GOTO predictor.
On 06/22/2017 12:27 PM, Richard Biener wrote: > On Wed, Jun 21, 2017 at 3:06 PM, Martin Liškawrote: >> Hello. >> >> There's one additional predictor enhancement that is GOTO predict that >> used to working. Following patch adds expect statement for C and C++ family >> languages. >> >> There's one fallout which is vrp24.c test-case, where only 'Simplified >> relational' >> appears just once. Adding Richi and Patrick who can probably help how to fix >> the >> test-case. > > Happens to be optimized better now, there's only one predicate to simplify > left in the IL input to VRP1. I suggest to change it to match 1 times and add > -fdump-tree-optimized to dg-options and > > /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ > > to verify we have 3 conditions left. Thanks for help. What about the comment: /* The first n_sets > 0 test can be simplfiied into n_sets == 1 since n_sets can only have the values [0, 1] as it's the result of a boolean operation. The second n_sets > 0 test can also be simplified into n_sets == 1 as the only way to reach the tests is when n_sets <= 1 and the only value which satisfies both conditions is n_sets == 1. */ I guess just only one can be valid? Or is it a different story now? Martin > >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >> >> Ready to be installed? >> Martin
Re: [PATCH 4/N] Recover GOTO predictor.
On Wed, Jun 21, 2017 at 3:06 PM, Martin Liškawrote: > Hello. > > There's one additional predictor enhancement that is GOTO predict that > used to working. Following patch adds expect statement for C and C++ family > languages. > > There's one fallout which is vrp24.c test-case, where only 'Simplified > relational' > appears just once. Adding Richi and Patrick who can probably help how to fix > the > test-case. Happens to be optimized better now, there's only one predicate to simplify left in the IL input to VRP1. I suggest to change it to match 1 times and add -fdump-tree-optimized to dg-options and /* { dg-final { scan-tree-dump-times "if " 3 "optimized" } } */ to verify we have 3 conditions left. > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? > Martin
Re: [PATCH 4/N] Recover GOTO predictor.
On 06/21/2017 03:06 PM, Martin Liška wrote: > Hello. > > There's one additional predictor enhancement that is GOTO predict that > used to working. Following patch adds expect statement for C and C++ family > languages. > > There's one fallout which is vrp24.c test-case, where only 'Simplified > relational' > appears just once. Adding Richi and Patrick who can probably help how to fix > the > test-case. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? > Martin > And I forgot to mention hitrate on SPEC2017: HEURISTICS BRANCHES (REL) BR. HITRATE HITRATE COVERAGE COVERAGE (REL) predict.def (REL) goto 622 1.0% 64.31% 65.92% / 83.70% 725127790 725.13M 0.1% Which says it's quite rare predictor, but with quite nice hitrate. Martin
[PATCH 4/N] Recover GOTO predictor.
Hello. There's one additional predictor enhancement that is GOTO predict that used to working. Following patch adds expect statement for C and C++ family languages. There's one fallout which is vrp24.c test-case, where only 'Simplified relational' appears just once. Adding Richi and Patrick who can probably help how to fix the test-case. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin ;; Function sss (sss, funcdef_no=0, decl_uid=1811, cgraph_uid=0, symbol_order=0) ;; 3 loops found ;; ;; Loop 0 ;; header 0, latch 1 ;; depth 0, outer -1 ;; nodes: 0 1 2 3 4 5 6 7 8 9 10 11 12 ;; 2 succs { 10 3 } ;; 3 succs { 4 8 } ;; 4 succs { 10 5 } ;; 5 succs { 12 } ;; 6 succs { 7 } ;; 7 succs { 9 } ;; 8 succs { 12 } ;; 9 succs { 12 } ;; 10 succs { 6 11 } ;; 11 succs { 9 } ;; 12 succs { 1 } SSA form after inserting ASSERT_EXPRs sss (struct rtx_def * insn, int code1, int code2, int code3) { int D1544; int n_sets; struct rtx_def * body; _Bool D1562; [100.00%] [count: INV]: body_5 = insn_4(D)->u.fld[5].rt_rtx; D1544_6 = body_5->code; if (D1544_6 == 55) goto (L7); [34.00%] [count: INV] else goto ; [66.00%] [count: INV] [66.00%] [count: INV]: if (code3_7(D) == 99) goto ; [34.00%] [count: INV] else goto ; [66.00%] [count: INV] [22.44%] [count: INV]: D1562_9 = code1_8(D) == 10; n_sets_10 = (int) D1562_9; if (n_sets_10 > 0) goto (L7); [64.00%] [count: INV] else goto ; [36.00%] [count: INV] [8.10%] [count: INV]: # n_sets_1 = PHI <0(4)> goto (L16); [100.00%] [count: INV] [9.79%] [count: INV]: arf (); [9.82%] [count: INV]: # n_sets_19 = PHI <1(6)> goto ; [100.00%] [count: INV] [43.56%] [count: INV]: # n_sets_21 = PHI <0(3)> goto (L16); [100.00%] [count: INV] [46.68%] [count: INV]: frob (); goto (L16); [100.00%] [count: INV] L7 [48.36%] [count: INV]: if (code2_12(D) == 42) goto ; [20.24%] [count: INV] else goto ; [79.76%] [count: INV] [38.61%] [count: INV]: # n_sets_17 = PHI <1(10)> goto ; [100.00%] [count: INV] L16 [100.00%] [count: INV]: return; } Immediate_uses: n_sets_1 : --> no uses. .MEM_2 : --> single use. # VUSE <.MEM_2> return; .MEM_3(D) : -->6 uses. .MEM_22 = PHI <.MEM_3(D)(3)> .MEM_18 = PHI <.MEM_3(D)(10)> .MEM_16 = PHI <.MEM_3(D)(4)> # .MEM_13 = VDEF <.MEM_3(D)> arf (); # VUSE <.MEM_3(D)> D1544_6 = body_5->code; # VUSE <.MEM_3(D)> body_5 = insn_4(D)->u.fld[5].rt_rtx; insn_4(D) : --> single use. body_5 = insn_4(D)->u.fld[5].rt_rtx; body_5 : --> single use. D1544_6 = body_5->code; D1544_6 : --> single use. if (D1544_6 == 55) code3_7(D) : --> single use. if (code3_7(D) == 99) code1_8(D) : --> single use. D1562_9 = code1_8(D) == 10; D1562_9 : --> single use. n_sets_10 = (int) D1562_9; n_sets_10 : --> single use. if (n_sets_10 > 0) code2_12(D) : --> single use. if (code2_12(D) == 42) .MEM_13 : --> single use. .MEM_20 = PHI <.MEM_13(6)> .MEM_14 : --> single use. .MEM_2 = PHI <.MEM_14(9), .MEM_22(8), .MEM_16(5)> .MEM_16 : --> single use. .MEM_2 = PHI <.MEM_14(9), .MEM_22(8), .MEM_16(5)> n_sets_17 : --> no uses. .MEM_18 : --> single use. .MEM_23 = PHI <.MEM_20(7), .MEM_18(11)> n_sets_19 : --> no uses. .MEM_20 : --> single use. .MEM_23 = PHI <.MEM_20(7), .MEM_18(11)> n_sets_21 : --> no uses. .MEM_22 : --> single use. .MEM_2 = PHI <.MEM_14(9), .MEM_22(8), .MEM_16(5)> .MEM_23 : --> single use. # .MEM_14 = VDEF <.MEM_23> frob (); Adding destination of edge (0 -> 2) to worklist Simulating block 2 Visiting statement: if (D1544_6 == 55) Visiting conditional with predicate: if (D1544_6 == 55) With known ranges D1544_6: VARYING Predicate evaluates to: DON'T KNOW Adding destination of edge (2 -> 10) to worklist Adding destination of edge (2 -> 3) to worklist Simulating block 3 Visiting statement: if (code3_7(D) == 99) Visiting conditional with predicate: if (code3_7(D) == 99) With known ranges code3_7(D): [] Predicate evaluates to: DON'T KNOW Adding destination of edge (3 -> 4) to worklist Adding destination of edge (3 -> 8) to worklist Simulating block 8 Visiting PHI node: n_sets_21 = PHI <0(3)> Argument #0 (3 -> 8 executable) 0: [0, 0] Intersecting [0, 0] and [0, 1] to [0, 0] Found new range for n_sets_21: [0, 0] marking stmt to be not simulated again Adding destination of edge (8 -> 12) to worklist Simulating block 4 Visiting statement: D1562_9 = code1_8(D) == 10; Intersecting [0, +INF] and [0, +INF] to [0, +INF] Found new range for D1562_9: [0, +INF] marking stmt to be not simulated again Visiting statement: n_sets_10 = (int) D1562_9; Intersecting [0, 1] and [0, 1] to [0, 1] Found new range for n_sets_10: [0, 1] marking stmt to be not simulated again Visiting statement: if (n_sets_10 > 0) Visiting conditional with predicate: if (n_sets_10 > 0) With known ranges n_sets_10: [0, 1] Predicate evaluates to: DON'T KNOW Adding destination of edge (4