[Bug 1202027] New: libgccjit.so and cc1obj text sections differs in size
https://bugzilla.suse.com/show_bug.cgi?id=1202027 Bug ID: 1202027 Summary: libgccjit.so and cc1obj text sections differs in size Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs@suse.de Reporter: rguenther@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- gcc12 seems to be not reproducible and one of the difference is visible in the libgccjit package which, for libgccjit.so itself is visible in different sized .text and .rodata: [16] .text PROGBITS 00000000002b97a0 002b97a0 - 0000000001105e42 0000000000000000 AX 0 0 16 - [17] .fini PROGBITS 00000000013bf5e4 013bf5e4 + 0000000001105c82 0000000000000000 AX 0 0 16 + [17] .fini PROGBITS 00000000013bf424 013bf424 000000000000000d 0000000000000000 AX 0 0 4 [18] .rodata PROGBITS 00000000013c0000 013c0000 - 000000000042d950 0000000000000000 A 0 0 32 - [19] .stapsdt.base PROGBITS 00000000017ed950 017ed950 + 000000000042d8f0 0000000000000000 A 0 0 32 disassembly starts with a huge blob of Disassembly of section .text: 00000000002b97a0 <gcc_jit_compatible_types@@LIBGCCJIT_ABI_20-0x1098dc0>: ... 0000000001352560 <gcc_jit_compatible_types@@LIBGCCJIT_ABI_20>: 1352560: f3 0f 1e fa endbr64 which isn't very useful unfortunately. Similar can be observed with cc1obj: [17] .text PROGBITS 0000000000624690 00224690 - 00000000012796dc 0000000000000000 AX 0 0 16 - [18] .fini PROGBITS 000000000189dd6c 0149dd6c + 00000000012796cc 0000000000000000 AX 0 0 16 the disassembly isn't too usable either, it starts within a blob with local functions as well. Since this is all -fprofile-use (but with -fprofile-reproducible=parallel-runs) and with -flto debugging this is hard. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mliska@suse.cz -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c1 --- Comment #1 from Richard Biener <rguenther@suse.com> --- There are differences in gcda like @@ -1,7 +1,7 @@ gimple-match.gcda:data:magic `gcda':version `B21*' -gimple-match.gcda:stamp 1483659858 +gimple-match.gcda:stamp 1483764244 gimple-match.gcda:checksum 2047081074 -gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967228784 +gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967227559 gimple-match.gcda: 01000000: 12:FUNCTION ident=791600706, lineno_checksum=0x29e79d07, cfg_checksum=0xdb3053ac gimple-match.gcda: 01a10000: 24:COUNTERS arcs 3 counts (all zero) gimple-match.gcda: 01a30000: 0:COUNTERS interval 0 counts or @@ -1,7 +1,7 @@ gimple.gcda:data:magic `gcda':version `B21*' -gimple.gcda:stamp 1483665359 +gimple.gcda:stamp 1483770318 gimple.gcda:checksum 1688754586 -gimple.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967228784 +gimple.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967227559 gimple.gcda: 01000000: 12:FUNCTION ident=1440623607, lineno_checksum=0xf7869597, cfg_checksum=0xa43083b8 gimple.gcda: 01a10000: 8:COUNTERS arcs 1 counts gimple.gcda: 01a70000: 0:COUNTERS topn 0 counts but for example gcc.gcda has same sum_max of 84860534 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c2 --- Comment #2 from Richard Biener <rguenther@suse.com> --- two build roots are available on tiber:/home/rguenther/oscbuildroot{1,2} -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c3 --- Comment #3 from Richard Biener <rguenther@suse.com> --- dumping with -l shows additional (a lot of) differences: @@ -1,7 +1,7 @@ gimple-match.gcda:data:magic `gcda':version `B21*' -gimple-match.gcda:stamp 1483659858 +gimple-match.gcda:stamp 1483764244 gimple-match.gcda:checksum 2047081074 -gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967228784 +gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967227559 gimple-match.gcda: 01000000: 12:FUNCTION ident=791600706, lineno_checksum=0x29e79d07, cfg_checksum=0xdb3053ac gimple-match.gcda: 01a10000: 24:COUNTERS arcs 3 counts (all zero) gimple-match.gcda: 0: 0 0 0 @@ -2240,24 +2240,24 @@ gimple-match.gcda: 104: 887567714 77 77 1 887567714 77 552 3 gimple-match.gcda: 112: 887567714 544 254370539 6 806698082 2 552 3 gimple-match.gcda: 120: 887567714 544 254370539 6 806698082 2 8724 8 -gimple-match.gcda: 128: 887567714 7033 806698082 305 254370539 1294 1597189827 20 +gimple-match.gcda: 128: 806698082 305 887567714 7033 254370539 1294 1597189827 20 and more like this. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c4 Martin Li��ka <martin.liska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.liska@suse.com --- Comment #4 from Martin Li��ka <martin.liska@suse.com> --- (In reply to Richard Biener from comment #3)
dumping with -l shows additional (a lot of) differences:
@@ -1,7 +1,7 @@ gimple-match.gcda:data:magic `gcda':version `B21*' -gimple-match.gcda:stamp 1483659858 +gimple-match.gcda:stamp 1483764244 gimple-match.gcda:checksum 2047081074 -gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967228784 +gimple-match.gcda: a1000000: 8:OBJECT_SUMMARY runs=2417, sum_max=3967227559 gimple-match.gcda: 01000000: 12:FUNCTION ident=791600706, lineno_checksum=0x29e79d07, cfg_checksum=0xdb3053ac gimple-match.gcda: 01a10000: 24:COUNTERS arcs 3 counts (all zero) gimple-match.gcda: 0: 0 0 0 @@ -2240,24 +2240,24 @@ gimple-match.gcda: 104: 887567714 77 77 1 887567714 77 552 3 gimple-match.gcda: 112: 887567714 544 254370539 6 806698082 2 552 3 gimple-match.gcda: 120: 887567714 544 254370539 6 806698082 2 8724 8 -gimple-match.gcda: 128: 887567714 7033 806698082 305 254370539 1294 1597189827 20 +gimple-match.gcda: 128: 806698082 305 887567714 7033 254370539 1294 1597189827 20
and more like this.
Well, these are actually indirect_call counters of the following format: (fn_id, fn_count) and these are only in a different order. When a profile is used we sort it by fn_count. But the sum_max difference means there are differences in arc counters as well. Let me find that.. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c5 --- Comment #5 from Martin Li��ka <martin.liska@suse.com> --- The arc difference are the following: < c-attribs.gcda 01a10000: 32:COUNTERS arcs 4 counts: 318596 67431 45480 45650
c-attribs.gcda 01a10000: 32:COUNTERS arcs 4 counts: 318591 67436 45492 45646 < c-attribs.gcda 01a10000: 72:COUNTERS arcs 9 counts: 426843 0 863038 919978 1052677 1604453 1604453 445801 919978 c-attribs.gcda 01a10000: 72:COUNTERS arcs 9 counts: 426831 0 863053 919975 1052671 1604278 1604278 445786 919975 < c-attribs.gcda 01a10000: 112:COUNTERS arcs 14 counts: 1256272 1381 1381 540646 0 428143 328285 0 407472 0 66555 0 0 761574 c-attribs.gcda 01a10000: 112:COUNTERS arcs 14 counts: 1256272 1381 1381 540645 0 428143 328292 0 407402 0 66555 0 0 761574 < c-attribs.gcda 01a10000: 8:COUNTERS arcs 1 counts: 2243681 c-attribs.gcda 01a10000: 8:COUNTERS arcs 1 counts: 2243683 < cfg.gcda 01a10000: 48:COUNTERS arcs 6 counts: 0 514018 5100 513056 6062 519118 cfg.gcda 01a10000: 48:COUNTERS arcs 6 counts: 0 514023 5095 513056 6062 519118 < cgraphunit.gcda 01a10000: 112:COUNTERS arcs 14 counts: 60259 699 699 11462 0 27662 20898 0 35353 0 13201 0 0 19396 cgraphunit.gcda 01a10000: 112:COUNTERS arcs 14 counts: 60259 699 699 11453 0 27662 20929 0 35367 0 13201 0 0 19396 < ggc-page.gcda 01a10000: 128:COUNTERS arcs 16 counts: 1737770547 79321 23081183 1714610043 23160504 23160504 2396 79321 23081183 12592214 58009499 40264779 81900 15208587 4213765 4213765 ggc-page.gcda 01a10000: 128:COUNTERS arcs 16 counts: 1737770547 79321 23081184 1714610042 23160505 23160505 2396 79321 23081184 12592214 58009499 40264780 81900 15208587 4213765 4213765 < ggc-page.gcda 01a10000: 120:COUNTERS arcs 15 counts: 23000934 191969804 3914 2959665 20041269 44837 114733 44837 0 0 22911707 44837 114733 20200839 23160504 ggc-page.gcda 01a10000: 120:COUNTERS arcs 15 counts: 23000935 191969804 3914 2959665 20041270 44837 114733 44837 0 0 22911707 44837 114733 20200840 23160505 < ggc-page.gcda 01a10000: 48:COUNTERS arcs 6 counts: 24660891 0 2396 2396 9509 9509 ggc-page.gcda 01a10000: 48:COUNTERS arcs 6 counts: 24660892 0 2396 2396 9509 9509 < ggc-page.gcda 01a10000: 32:COUNTERS arcs 4 counts: 23160504 11414 11414 11414 ggc-page.gcda 01a10000: 32:COUNTERS arcs 4 counts: 23160505 11414 11414 11414 < ipa-cp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 6029 8 8 4143 0 1539 245 0 240 0 116 0 0 4374 ipa-cp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 6029 8 8 4139 0 1539 242 0 232 0 116 0 0 4374 < ipa-cp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 9821 4 4 7420 0 2268 54 0 49 0 24 0 0 7529 ipa-cp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 9821 4 4 7420 0 2268 56 0 49 0 24 0 0 7529 < ipa-icf.gcda 01a10000: 32:COUNTERS arcs 4 counts: 348088 79107 53072 53276 ipa-icf.gcda 01a10000: 32:COUNTERS arcs 4 counts: 348083 79112 53139 53225 < ipa-icf.gcda 01a10000: 88:COUNTERS arcs 11 counts: 40451 663329 0 476704 449316 199597 351752 0 181736 165368 214013 ipa-icf.gcda 01a10000: 88:COUNTERS arcs 11 counts: 40445 663335 0 476690 449346 199699 351874 0 181678 165338 213989 < ipa-icf.gcda 01a10000: 128:COUNTERS arcs 16 counts: 476582 3586 3586 144090 0 166935 125630 231559 0 302675 0 90418 43666 0 0 307286 ipa-icf.gcda 01a10000: 128:COUNTERS arcs 16 counts: 476582 3586 3586 144156 0 167063 125804 231227 0 302271 0 90273 43492 0 0 307286 < ipa-icf.gcda 01a10000: 24:COUNTERS arcs 3 counts: 242 222 222 ipa-icf.gcda 01a10000: 24:COUNTERS arcs 3 counts: 236 228 228 < ipa-icf.gcda 01a10000: 8:COUNTERS arcs 1 counts: 2663422 ipa-icf.gcda 01a10000: 8:COUNTERS arcs 1 counts: 2663403 < ipa-ref.gcda 01a10000: 8:COUNTERS arcs 1 counts: 4690996 ipa-ref.gcda 01a10000: 8:COUNTERS arcs 1 counts: 4690875 < ira-conflicts.gcda 01a10000: 24:COUNTERS arcs 3 counts: 1336536 0 4026706 ira-conflicts.gcda 01a10000: 24:COUNTERS arcs 3 counts: 1336521 0 4026706 < ira-lives.gcda 01a10000: 24:COUNTERS arcs 3 counts: 30403871 9270516 36841799 ira-lives.gcda 01a10000: 24:COUNTERS arcs 3 counts: 30403717 9270516 36841799 < lra-assigns.gcda 01a10000: 24:COUNTERS arcs 3 counts: 20190122 8653848 31634603 lra-assigns.gcda 01a10000: 24:COUNTERS arcs 3 counts: 20190125 8653848 31634603 < lra-lives.gcda 01a10000: 24:COUNTERS arcs 3 counts: 352864337 218294838 330242570 lra-lives.gcda 01a10000: 24:COUNTERS arcs 3 counts: 352863966 218294838 330242570 < lto-common.gcda 01a10000: 8:COUNTERS arcs 1 counts: 62502 lto-common.gcda 01a10000: 8:COUNTERS arcs 1 counts: 60477 < lto-streamer-out.gcda 01a10000: 112:COUNTERS arcs 14 counts: 628056 6254 6254 380145 0 112018 145998 0 183260 0 30786 0 0 485252 lto-streamer-out.gcda 01a10000: 112:COUNTERS arcs 14 counts: 628056 6254 6254 380145 0 112018 146003 0 183262 0 30786 0 0 485252 < sparseset.gcda 01a10000: 24:COUNTERS arcs 3 counts: 115694465 103713224 47127027 sparseset.gcda 01a10000: 24:COUNTERS arcs 3 counts: 115694484 103713224 47127027 < symtab.gcda 01a10000: 120:COUNTERS arcs 15 counts: 445200 1827689 445200 153686 2119203 153686 14287 153686 0 2119203 0 1719512 0 2456617 2456617 symtab.gcda 01a10000: 120:COUNTERS arcs 15 counts: 445200 1827689 445200 153686 2119203 153686 14287 153686 0 2119203 0 1719526 0 2456496 2456496 < tree-loop-distribution.gcda 01a10000: 128:COUNTERS arcs 16 counts: 8570 0 0 5009 0 3457 3428 95 0 61 0 12 6 0 0 5136 tree-loop-distribution.gcda 01a10000: 128:COUNTERS arcs 16 counts: 8570 0 0 5009 0 3457 3428 94 0 61 0 12 6 0 0 5136 < tree-ssa-sccvn.gcda 01a10000: 120:COUNTERS arcs 15 counts: 173076 0 1182492 3774328 173076 813073 173076 2381771 2381771 171184 1892 169334 173076 2970672 159827 tree-ssa-sccvn.gcda 01a10000: 120:COUNTERS arcs 15 counts: 173076 0 1182492 3774328 173076 813073 173076 2381771 2381771 171175 1901 169334 173076 2970672 159827 < tree-ssa-structalias.gcda 01a10000: 32:COUNTERS arcs 4 counts: 6716243 838947 591630 600274 tree-ssa-structalias.gcda 01a10000: 32:COUNTERS arcs 4 counts: 6715765 839425 591883 600922 < tree-ssa-structalias.gcda 01a10000: 32:COUNTERS arcs 4 counts: 13175176 3314121 2330272 2326475 tree-ssa-structalias.gcda 01a10000: 32:COUNTERS arcs 4 counts: 13175253 3314044 2330322 2326355 < tree-ssa-structalias.gcda 01a10000: 112:COUNTERS arcs 14 counts: 10415289 227400 227400 4764603 0 2252884 4153613 0 5680585 0 643696 0 0 7518709 tree-ssa-structalias.gcda 01a10000: 112:COUNTERS arcs 14 counts: 10415289 227400 227400 4764868 0 2252765 4154494 0 5681392 0 643815 0 0 7518709 < tree-ssa-structalias.gcda 01a10000: 72:COUNTERS arcs 9 counts: 6523297 0 21588630 19056002 22444589 37625164 37625164 11939190 19056002 tree-ssa-structalias.gcda 01a10000: 72:COUNTERS arcs 9 counts: 6523074 0 21588152 19056703 22446539 37627261 37627261 11939668 19056703 < tree-ssa-structalias.gcda 01a10000: 112:COUNTERS arcs 14 counts: 14329444 390044 390044 7415165 0 0 8658767 0 10348631 0 0 0 0 14329444 tree-ssa-structalias.gcda 01a10000: 112:COUNTERS arcs 14 counts: 14329444 390044 390044 7414958 0 0 8658890 0 10348969 0 0 0 0 14329444 < tree-ssa-structalias.gcda 01a10000: 8:COUNTERS arcs 1 counts: 103236821 tree-ssa-structalias.gcda 01a10000: 8:COUNTERS arcs 1 counts: 103237923 < tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 19037 3848 2524 2522 tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 19030 3855 2524 2527 < tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 89205 16905 11297 11379 tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 89193 16917 11300 11417 < tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 100854 18346 12273 12323 tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 100837 18363 12283 12353 < tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 453497 25205 17327 16879 tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 453499 25205 17324 16874 < tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 2437940 4051054 81533 199481 tree-vect-slp.gcda 01a10000: 32:COUNTERS arcs 4 counts: 2437949 4051004 81533 199481 < tree-vect-slp.gcda 01a10000: 80:COUNTERS arcs 10 counts: 871 475 0 16083 154137 478702 8515 16954 0 0 tree-vect-slp.gcda 01a10000: 80:COUNTERS arcs 10 counts: 871 475 0 16083 154137 478704 8513 16954 0 0 < tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 83385 0 85346 228 182 213 213 80 228 tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 83385 0 85346 228 179 211 211 80 228 < tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 83533 36 36 83393 0 0 104 0 81 0 0 0 0 83533 tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 83533 36 36 83393 0 0 101 0 79 0 0 0 0 83533 < tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 80567 931 931 65092 0 589 13805 0 13644 0 219 0 0 79759 tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 80567 931 931 65115 0 584 13786 0 13608 0 224 0 0 79759 < tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 205269 3833 3833 141620 0 5700 58637 0 63256 0 1885 0 0 197684 tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 205269 3833 3833 141650 0 5705 58527 0 63103 0 1880 0 0 197684 < tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 0 0 73868 11992 8754 18335 18335 11992 11992 tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 0 0 73858 12002 8779 18337 18337 12002 12002 < tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 141103 3 13315 59806 62722 69645 69643 1574 59806 tree-vect-slp.gcda 01a10000: 72:COUNTERS arcs 9 counts: 141143 3 13316 59765 62602 69461 69459 1573 59765 < tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 483459 4518 4518 466415 1471 12945 79288 2801 77324 388 3343 73739 1537 473446 tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 483459 4518 4518 466493 1465 12944 79212 2800 77232 387 3344 73739 1532 473451 < tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 1747647 16954 16954 1556737 27145 122353 191965 31973 223219 6332 22270 0 33322 1653098 tree-vect-slp.gcda 01a10000: 112:COUNTERS arcs 14 counts: 1747647 16954 16954 1556713 27147 122351 192033 31961 223396 6332 22272 0 33324 1653096 < tree-vect-slp.gcda 01a10000: 8:COUNTERS arcs 1 counts: 3350564 tree-vect-slp.gcda 01a10000: 8:COUNTERS arcs 1 counts: 3350569 < tree-vect-slp.gcda 01a10000: 8:COUNTERS arcs 1 counts: 4737455 tree-vect-slp.gcda 01a10000: 8:COUNTERS arcs 1 counts: 4737457 < varasm.gcda 01a10000: 32:COUNTERS arcs 4 counts: 12795 2983 1983 1943 varasm.gcda 01a10000: 32:COUNTERS arcs 4 counts: 12811 2967 1983 1947 < varasm.gcda 01a10000: 128:COUNTERS arcs 16 counts: 1307721 408 408 26127 1281594 352177 1281594 929417 345074 0 674262 0 333244 0 0 45060 varasm.gcda 01a10000: 128:COUNTERS arcs 16 counts: 1307721 408 408 26107 1281614 352197 1281614 929417 345054 0 674262 0 333244 0 0 45060 < varasm.gcda 01a10000: 8:COUNTERS arcs 1 counts: 1955856 varasm.gcda 01a10000: 8:COUNTERS arcs 1 counts: 1955876 < varasm.gcda 01a10000: 8:COUNTERS arcs 1 counts: 1761153 varasm.gcda 01a10000: 8:COUNTERS arcs 1 counts: 1761137 < var-tracking.gcda 01a10000: 32:COUNTERS arcs 4 counts: 5531169 672817 422919 456890 var-tracking.gcda 01a10000: 32:COUNTERS arcs 4 counts: 5531216 672770 422992 457052 < var-tracking.gcda 01a10000: 72:COUNTERS arcs 9 counts: 59998 0 1451407 550566 561277 1166016 1166016 550140 550566 var-tracking.gcda 01a10000: 72:COUNTERS arcs 9 counts: 59998 0 1451456 550517 561486 1166363 1166363 550091 550517 < var-tracking.gcda 01a10000: 112:COUNTERS arcs 14 counts: 30407385 378370 378370 6364968 0 18007037 5362792 0 8326743 0 3336227 0 0 9064121 var-tracking.gcda 01a10000: 112:COUNTERS arcs 14 counts: 30407385 378370 378370 6365514 0 18008082 5362796 0 8325478 0 3335182 0 0 9064121 < var-tracking.gcda 01a10000: 8:COUNTERS arcs 1 counts: 657602650 var-tracking.gcda 01a10000: 8:COUNTERS arcs 1 counts: 657602554
-- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c6 --- Comment #6 from Martin Li��ka <martin.liska@suse.com> --- Created attachment 860520 --> https://bugzilla.suse.com/attachment.cgi?id=860520&action=edit arc diff -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c7 --- Comment #7 from Martin Li��ka <martin.liska@suse.com> --- Ok, I've just made 2 builds with profiledbootstrap and --with-build-config=bootstrap-lto on a machine where ASLR is disabled but still we face so arc counter differences in hash table related functions like htab_find_slot_with_hash, htab_mod, ... Well, very many hash tables are pointer-based on based on the address hash is different and so table collisions are not stable. I think it's an unrealistic assumption that the memory layout of 2 running compiler invocations will be always the same, right?! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c8 --- Comment #8 from Richard Biener <rguenther@suse.com> --- (In reply to Martin Li��ka from comment #7)
Ok, I've just made 2 builds with profiledbootstrap and --with-build-config=bootstrap-lto on a machine where ASLR is disabled but still we face so arc counter differences in hash table related functions like htab_find_slot_with_hash, htab_mod, ... Well, very many hash tables are pointer-based on based on the address hash is different and so table collisions are not stable. I think it's an unrealistic assumption that the memory layout of 2 running compiler invocations will be always the same, right?!
The gcc package also disables ASLR. But yes, I think that with ASLR disabled pointer hash table behavior should reproduce exactly. At least I can't find a good reason why it should not? Btw, I wanted to check whether the issue reproduces also without LTO ... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c9 --- Comment #9 from Martin Li��ka <martin.liska@suse.com> ---
At least I can't find a good reason why it should not?
For instance, a temporary file name can have a different length and cause a bit different memory fragmentation, but who knows.. Lemme try the non-LTO buids.. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c10 --- Comment #10 from Richard Biener <rguenther@suse.com> --- (In reply to Martin Li��ka from comment #9)
At least I can't find a good reason why it should not?
For instance, a temporary file name can have a different length and cause a bit different memory fragmentation, but who knows..
I think mktemp & friends produce consistent lengths (good) but just different characters (sometimes problematic). Of course filesystem activity might need different amounts of memory internally but that's hopefully released...
Lemme try the non-LTO buids..
Those should at least be easier to analyze - I'm crossing my fingers ;) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c13 --- Comment #13 from Richard Biener <rguenther@suse.com> --- OK, so that mixes different kind of hashes and likely includes string hashing eventually hashing temporary filenames. So do we need to annotate this function with no_instrument_function? Does that even help or are there othe functions affected as well? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c14 --- Comment #14 from Martin Li��ka <martin.liska@suse.com> --- These functions are affected: ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE26find_empty_slot_for_expandEj, funcdef_no=3135, decl_uid=118436, cgraph_uid=2254, symbol_order=2435) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE19find_slot_with_hashERKS2_j13insert_option, funcdef_no=2928, decl_uid=118365, cgraph_uid=2047, symbol_order=2228) ;; Function hash_table_mod2 (_Z15hash_table_mod2jj, funcdef_no=1065, decl_uid=33219, cgraph_uid=354, symbol_order=368) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_hash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE26find_empty_slot_for_expandEj, funcdef_no=3327, decl_uid=112248, cgraph_uid=2446, symbol_order=2623) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_hash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE19find_slot_with_hashERKS2_j13insert_option, funcdef_no=3056, decl_uid=112177, cgraph_uid=2175, symbol_order=2352) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_hash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=3048, decl_uid=112166, cgraph_uid=2167, symbol_order=2344) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=2698, decl_uid=118471, cgraph_uid=1818, symbol_order=2019) ;; Function get_terminal_width (_Z18get_terminal_widthv, funcdef_no=1638, decl_uid=40874, cgraph_uid=752, symbol_order=778) ;; Function hash_table<indirect_string_hasher>::find_slot_with_hash (_ZN10hash_tableI22indirect_string_hasherLb0E11xcallocatorE19find_slot_with_hashERKPKcj13insert_option, funcdef_no=3536, decl_uid=133145, cgraph_uid=2647, symbol_order=2952) ;; Function ggc_internal_cleared_alloc (_Z26ggc_internal_cleared_allocmPFvPvEmm, funcdef_no=1531, decl_uid=30171, cgraph_uid=670, symbol_order=708) ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833) ;; Function ggc_round_alloc_size_1 (_ZL22ggc_round_alloc_size_1mPmS_, funcdef_no=2548, decl_uid=116089, cgraph_uid=1659, symbol_order=1830) ;; Function hash_table<int_cst_hasher>::find_slot_with_hash (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE19find_slot_with_hashERKP9tree_nodej13insert_option, funcdef_no=4799, decl_uid=145332, cgraph_uid=3868, symbol_order=4076) ;; Function generic_wide_int<wide_int_ref_storage<true, false> >::sign_mask (_ZNK16generic_wide_intI20wide_int_ref_storageILb1ELb0EEE9sign_maskEv, funcdef_no=4766, decl_uid=17596, cgraph_uid=3835, symbol_order=4043) ;; Function hash_table<int_cst_hasher>::find_slot (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE9find_slotERKP9tree_node13insert_option, funcdef_no=4313, decl_uid=145328, cgraph_uid=3382, symbol_order=3590) ;; Function generic_wide_int<wide_int_storage>::elt (_ZNK16generic_wide_intI16wide_int_storageE3eltEj, funcdef_no=4291, decl_uid=16632, cgraph_uid=3360, symbol_order=3568) ;; Function wi::neg_p<generic_wide_int<wide_int_storage> > (_ZN2wi5neg_pI16generic_wide_intI16wide_int_storageEEEbRKT_6signop, funcdef_no=4290, decl_uid=148263, cgraph_uid=3359, symbol_order=3567) ;; Function make_int_cst (_Z12make_int_cstii, funcdef_no=3624, decl_uid=102817, cgraph_uid=2697, symbol_order=2893) ;; Function wide_int_to_tree_1 (_ZL18wide_int_to_tree_1P9tree_nodeRK16generic_wide_intI20wide_int_ref_storageILb0ELb1EEE, funcdef_no=3573, decl_uid=149059, cgraph_uid=2646, symbol_order=2842) ;; Function cache_wide_int_in_type_cache (_ZL28cache_wide_int_in_type_cacheP9tree_nodeRK16generic_wide_intI16wide_int_storageEii, funcdef_no=3572, decl_uid=149054, cgraph_uid=2645, symbol_order=2841) ;; Function int_cst_hasher::equal (_ZN14int_cst_hasher5equalEP9tree_nodeS1_, funcdef_no=3571, decl_uid=144691, cgraph_uid=2644, symbol_order=2840) ;; Function int_cst_hasher::hash (_ZN14int_cst_hasher4hashEP9tree_node, funcdef_no=3570, decl_uid=144688, cgraph_uid=2643, symbol_order=2839) ;; Function build_new_int_cst (_ZL17build_new_int_cstP9tree_nodeRK16generic_wide_intI16wide_int_storageE, funcdef_no=3563, decl_uid=148268, cgraph_uid=2636, symbol_order=2832) ;; Function get_int_cst_ext_nunits (_ZL22get_int_cst_ext_nunitsP9tree_nodeRK16generic_wide_intI16wide_int_storageE, funcdef_no=3562, decl_uid=148261, cgraph_uid=2635, symbol_order=2831) ;; Function hash_table_mod1 (_Z15hash_table_mod1jj, funcdef_no=1064, decl_uid=33214, cgraph_uid=353, symbol_order=367) ;; Function iterative_hash_host_wide_int (_Z28iterative_hash_host_wide_intlj, funcdef_no=1014, decl_uid=32338, cgraph_uid=349, symbol_order=362) ;; Function default_elf_asm_output_ascii (_Z28default_elf_asm_output_asciiP8_IO_FILEPKcj, funcdef_no=2992, decl_uid=128822, cgraph_uid=2049, symbol_order=2260) ;; Function cpp_interpret_integer (_Z21cpp_interpret_integerP10cpp_readerPK9cpp_tokenj, funcdef_no=299, decl_uid=14009, cgraph_uid=202, symbol_order=220) ;; Function nonexistent_file_hash_eq (_ZL24nonexistent_file_hash_eqPKvS0_, funcdef_no=320, decl_uid=15648, cgraph_uid=223, symbol_order=243) ;; Function filename_cmp (filename_cmp, funcdef_no=25, decl_uid=3122, cgraph_uid=26, symbol_order=25) ;; Function htab_find_slot_with_hash (htab_find_slot_with_hash, funcdef_no=42, decl_uid=3888, cgraph_uid=43, symbol_order=45) ;; Function htab_find_with_hash (htab_find_with_hash, funcdef_no=40, decl_uid=3883, cgraph_uid=41, symbol_order=43) ;; Function find_empty_slot_for_expand (find_empty_slot_for_expand, funcdef_no=38, decl_uid=3946, cgraph_uid=39, symbol_order=41) ;; Function htab_mod_m2 (htab_mod_m2, funcdef_no=29, decl_uid=3936, cgraph_uid=30, symbol_order=32) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c15 --- Comment #15 from Richard Biener <rguenther@suse.com> --- (In reply to Martin Li��ka from comment #14)
These functions are affected:
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE26find_e mpty_slot_for_expandEj, funcdef_no=3135, decl_uid=118436, cgraph_uid=2254, symbol_order=2435)
That's a tree hash (I think using pointer hashing).
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE19find_s lot_with_hashERKS2_j13insert_option, funcdef_no=2928, decl_uid=118365, cgraph_uid=2047, symbol_order=2228) ;; Function hash_table_mod2 (_Z15hash_table_mod2jj, funcdef_no=1065, decl_uid=33219, cgraph_uid=354, symbol_order=368)
But this suggests the actual table load differs?!
;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE26find_empty_slot_for_expa ndEj, funcdef_no=3327, decl_uid=112248, cgraph_uid=2446, symbol_order=2623) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE19find_slot_with_hashERKS2 _j13insert_option, funcdef_no=3056, decl_uid=112177, cgraph_uid=2175, symbol_order=2352) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=3048, decl_uid=112166, cgraph_uid=2167, symbol_order=2344) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE14find_w ith_hashERKS2_j, funcdef_no=2698, decl_uid=118471, cgraph_uid=1818, symbol_order=2019) ;; Function get_terminal_width (_Z18get_terminal_widthv, funcdef_no=1638, decl_uid=40874, cgraph_uid=752, symbol_order=778) ;; Function hash_table<indirect_string_hasher>::find_slot_with_hash (_ZN10hash_tableI22indirect_string_hasherLb0E11xcallocatorE19find_slot_with_h ashERKPKcj13insert_option, funcdef_no=3536, decl_uid=133145, cgraph_uid=2647, symbol_order=2952) ;; Function ggc_internal_cleared_alloc (_Z26ggc_internal_cleared_allocmPFvPvEmm, funcdef_no=1531, decl_uid=30171, cgraph_uid=670, symbol_order=708) ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833)
And these suggest the same - do we see the invocation count of ggc_internal_alloc and does that differ?
;; Function ggc_round_alloc_size_1 (_ZL22ggc_round_alloc_size_1mPmS_, funcdef_no=2548, decl_uid=116089, cgraph_uid=1659, symbol_order=1830) ;; Function hash_table<int_cst_hasher>::find_slot_with_hash (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE19find_slot_with_hashERKP9 tree_nodej13insert_option, funcdef_no=4799, decl_uid=145332, cgraph_uid=3868, symbol_order=4076) ;; Function generic_wide_int<wide_int_ref_storage<true, false> >::sign_mask (_ZNK16generic_wide_intI20wide_int_ref_storageILb1ELb0EEE9sign_maskEv, funcdef_no=4766, decl_uid=17596, cgraph_uid=3835, symbol_order=4043) ;; Function hash_table<int_cst_hasher>::find_slot (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE9find_slotERKP9tree_node13 insert_option, funcdef_no=4313, decl_uid=145328, cgraph_uid=3382, symbol_order=3590) ;; Function generic_wide_int<wide_int_storage>::elt (_ZNK16generic_wide_intI16wide_int_storageE3eltEj, funcdef_no=4291, decl_uid=16632, cgraph_uid=3360, symbol_order=3568) ;; Function wi::neg_p<generic_wide_int<wide_int_storage> > (_ZN2wi5neg_pI16generic_wide_intI16wide_int_storageEEEbRKT_6signop, funcdef_no=4290, decl_uid=148263, cgraph_uid=3359, symbol_order=3567) ;; Function make_int_cst (_Z12make_int_cstii, funcdef_no=3624, decl_uid=102817, cgraph_uid=2697, symbol_order=2893) ;; Function wide_int_to_tree_1 (_ZL18wide_int_to_tree_1P9tree_nodeRK16generic_wide_intI20wide_int_ref_storag eILb0ELb1EEE, funcdef_no=3573, decl_uid=149059, cgraph_uid=2646, symbol_order=2842) ;; Function cache_wide_int_in_type_cache (_ZL28cache_wide_int_in_type_cacheP9tree_nodeRK16generic_wide_intI16wide_int_ storageEii, funcdef_no=3572, decl_uid=149054, cgraph_uid=2645, symbol_order=2841) ;; Function int_cst_hasher::equal (_ZN14int_cst_hasher5equalEP9tree_nodeS1_, funcdef_no=3571, decl_uid=144691, cgraph_uid=2644, symbol_order=2840) ;; Function int_cst_hasher::hash (_ZN14int_cst_hasher4hashEP9tree_node, funcdef_no=3570, decl_uid=144688, cgraph_uid=2643, symbol_order=2839) ;; Function build_new_int_cst (_ZL17build_new_int_cstP9tree_nodeRK16generic_wide_intI16wide_int_storageE, funcdef_no=3563, decl_uid=148268, cgraph_uid=2636, symbol_order=2832) ;; Function get_int_cst_ext_nunits (_ZL22get_int_cst_ext_nunitsP9tree_nodeRK16generic_wide_intI16wide_int_storag eE, funcdef_no=3562, decl_uid=148261, cgraph_uid=2635, symbol_order=2831) ;; Function hash_table_mod1 (_Z15hash_table_mod1jj, funcdef_no=1064, decl_uid=33214, cgraph_uid=353, symbol_order=367) ;; Function iterative_hash_host_wide_int (_Z28iterative_hash_host_wide_intlj, funcdef_no=1014, decl_uid=32338, cgraph_uid=349, symbol_order=362) ;; Function default_elf_asm_output_ascii (_Z28default_elf_asm_output_asciiP8_IO_FILEPKcj, funcdef_no=2992, decl_uid=128822, cgraph_uid=2049, symbol_order=2260) ;; Function cpp_interpret_integer (_Z21cpp_interpret_integerP10cpp_readerPK9cpp_tokenj, funcdef_no=299, decl_uid=14009, cgraph_uid=202, symbol_order=220) ;; Function nonexistent_file_hash_eq (_ZL24nonexistent_file_hash_eqPKvS0_, funcdef_no=320, decl_uid=15648, cgraph_uid=223, symbol_order=243) ;; Function filename_cmp (filename_cmp, funcdef_no=25, decl_uid=3122, cgraph_uid=26, symbol_order=25) ;; Function htab_find_slot_with_hash (htab_find_slot_with_hash, funcdef_no=42, decl_uid=3888, cgraph_uid=43, symbol_order=45) ;; Function htab_find_with_hash (htab_find_with_hash, funcdef_no=40, decl_uid=3883, cgraph_uid=41, symbol_order=43) ;; Function find_empty_slot_for_expand (find_empty_slot_for_expand, funcdef_no=38, decl_uid=3946, cgraph_uid=39, symbol_order=41) ;; Function htab_mod_m2 (htab_mod_m2, funcdef_no=29, decl_uid=3936, cgraph_uid=30, symbol_order=32)
in the end most of the above could be secondary order effects by getting different profile for different generated code? We profile the stage2 compiler after all? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c16 --- Comment #16 from Martin Li��ka <martin.liska@suse.com> --- (In reply to Richard Biener from comment #15)
(In reply to Martin Li��ka from comment #14)
These functions are affected:
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE26find_e mpty_slot_for_expandEj, funcdef_no=3135, decl_uid=118436, cgraph_uid=2254, symbol_order=2435)
That's a tree hash (I think using pointer hashing).
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE19find_s lot_with_hashERKS2_j13insert_option, funcdef_no=2928, decl_uid=118365, cgraph_uid=2047, symbol_order=2228) ;; Function hash_table_mod2 (_Z15hash_table_mod2jj, funcdef_no=1065, decl_uid=33219, cgraph_uid=354, symbol_order=368)
But this suggests the actual table load differs?!
;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE26find_empty_slot_for_expa ndEj, funcdef_no=3327, decl_uid=112248, cgraph_uid=2446, symbol_order=2623) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE19find_slot_with_hashERKS2 _j13insert_option, funcdef_no=3056, decl_uid=112177, cgraph_uid=2175, symbol_order=2352) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=3048, decl_uid=112166, cgraph_uid=2167, symbol_order=2344) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE14find_w ith_hashERKS2_j, funcdef_no=2698, decl_uid=118471, cgraph_uid=1818, symbol_order=2019) ;; Function get_terminal_width (_Z18get_terminal_widthv, funcdef_no=1638, decl_uid=40874, cgraph_uid=752, symbol_order=778) ;; Function hash_table<indirect_string_hasher>::find_slot_with_hash (_ZN10hash_tableI22indirect_string_hasherLb0E11xcallocatorE19find_slot_with_h ashERKPKcj13insert_option, funcdef_no=3536, decl_uid=133145, cgraph_uid=2647, symbol_order=2952) ;; Function ggc_internal_cleared_alloc (_Z26ggc_internal_cleared_allocmPFvPvEmm, funcdef_no=1531, decl_uid=30171, cgraph_uid=670, symbol_order=708) ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833)
And these suggest the same - do we see the invocation count of ggc_internal_alloc and does that differ?
Yes, it is: ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833) ... -Read edge from 0 to 2, count:1113521085 +Read edge from 0 to 2, count:1113521086 Read edge from 3 to 5, count:60717 Read edge from 4 to 5, count:14486906 -Read edge from 4 to 14, count:1098973462 +Read edge from 4 to 14, count:1098973463 The first edge is entry count.
;; Function ggc_round_alloc_size_1 (_ZL22ggc_round_alloc_size_1mPmS_, funcdef_no=2548, decl_uid=116089, cgraph_uid=1659, symbol_order=1830) ;; Function hash_table<int_cst_hasher>::find_slot_with_hash (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE19find_slot_with_hashERKP9 tree_nodej13insert_option, funcdef_no=4799, decl_uid=145332, cgraph_uid=3868, symbol_order=4076) ;; Function generic_wide_int<wide_int_ref_storage<true, false> >::sign_mask (_ZNK16generic_wide_intI20wide_int_ref_storageILb1ELb0EEE9sign_maskEv, funcdef_no=4766, decl_uid=17596, cgraph_uid=3835, symbol_order=4043) ;; Function hash_table<int_cst_hasher>::find_slot (_ZN10hash_tableI14int_cst_hasherLb0E11xcallocatorE9find_slotERKP9tree_node13 insert_option, funcdef_no=4313, decl_uid=145328, cgraph_uid=3382, symbol_order=3590) ;; Function generic_wide_int<wide_int_storage>::elt (_ZNK16generic_wide_intI16wide_int_storageE3eltEj, funcdef_no=4291, decl_uid=16632, cgraph_uid=3360, symbol_order=3568) ;; Function wi::neg_p<generic_wide_int<wide_int_storage> > (_ZN2wi5neg_pI16generic_wide_intI16wide_int_storageEEEbRKT_6signop, funcdef_no=4290, decl_uid=148263, cgraph_uid=3359, symbol_order=3567) ;; Function make_int_cst (_Z12make_int_cstii, funcdef_no=3624, decl_uid=102817, cgraph_uid=2697, symbol_order=2893) ;; Function wide_int_to_tree_1 (_ZL18wide_int_to_tree_1P9tree_nodeRK16generic_wide_intI20wide_int_ref_storag eILb0ELb1EEE, funcdef_no=3573, decl_uid=149059, cgraph_uid=2646, symbol_order=2842) ;; Function cache_wide_int_in_type_cache (_ZL28cache_wide_int_in_type_cacheP9tree_nodeRK16generic_wide_intI16wide_int_ storageEii, funcdef_no=3572, decl_uid=149054, cgraph_uid=2645, symbol_order=2841) ;; Function int_cst_hasher::equal (_ZN14int_cst_hasher5equalEP9tree_nodeS1_, funcdef_no=3571, decl_uid=144691, cgraph_uid=2644, symbol_order=2840) ;; Function int_cst_hasher::hash (_ZN14int_cst_hasher4hashEP9tree_node, funcdef_no=3570, decl_uid=144688, cgraph_uid=2643, symbol_order=2839) ;; Function build_new_int_cst (_ZL17build_new_int_cstP9tree_nodeRK16generic_wide_intI16wide_int_storageE, funcdef_no=3563, decl_uid=148268, cgraph_uid=2636, symbol_order=2832) ;; Function get_int_cst_ext_nunits (_ZL22get_int_cst_ext_nunitsP9tree_nodeRK16generic_wide_intI16wide_int_storag eE, funcdef_no=3562, decl_uid=148261, cgraph_uid=2635, symbol_order=2831) ;; Function hash_table_mod1 (_Z15hash_table_mod1jj, funcdef_no=1064, decl_uid=33214, cgraph_uid=353, symbol_order=367) ;; Function iterative_hash_host_wide_int (_Z28iterative_hash_host_wide_intlj, funcdef_no=1014, decl_uid=32338, cgraph_uid=349, symbol_order=362) ;; Function default_elf_asm_output_ascii (_Z28default_elf_asm_output_asciiP8_IO_FILEPKcj, funcdef_no=2992, decl_uid=128822, cgraph_uid=2049, symbol_order=2260) ;; Function cpp_interpret_integer (_Z21cpp_interpret_integerP10cpp_readerPK9cpp_tokenj, funcdef_no=299, decl_uid=14009, cgraph_uid=202, symbol_order=220) ;; Function nonexistent_file_hash_eq (_ZL24nonexistent_file_hash_eqPKvS0_, funcdef_no=320, decl_uid=15648, cgraph_uid=223, symbol_order=243) ;; Function filename_cmp (filename_cmp, funcdef_no=25, decl_uid=3122, cgraph_uid=26, symbol_order=25) ;; Function htab_find_slot_with_hash (htab_find_slot_with_hash, funcdef_no=42, decl_uid=3888, cgraph_uid=43, symbol_order=45) ;; Function htab_find_with_hash (htab_find_with_hash, funcdef_no=40, decl_uid=3883, cgraph_uid=41, symbol_order=43) ;; Function find_empty_slot_for_expand (find_empty_slot_for_expand, funcdef_no=38, decl_uid=3946, cgraph_uid=39, symbol_order=41) ;; Function htab_mod_m2 (htab_mod_m2, funcdef_no=29, decl_uid=3936, cgraph_uid=30, symbol_order=32)
in the end most of the above could be secondary order effects by getting different profile for different generated code? We profile the stage2 compiler after all?
Is a different generated code expected? Yes, we profile stage2 compiler. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c17 --- Comment #17 from Richard Biener <rguenther@suse.com> --- (In reply to Martin Li��ka from comment #16)
(In reply to Richard Biener from comment #15)
(In reply to Martin Li��ka from comment #14)
These functions are affected:
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE26find_e mpty_slot_for_expandEj, funcdef_no=3135, decl_uid=118436, cgraph_uid=2254, symbol_order=2435)
That's a tree hash (I think using pointer hashing).
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE19find_s lot_with_hashERKS2_j13insert_option, funcdef_no=2928, decl_uid=118365, cgraph_uid=2047, symbol_order=2228) ;; Function hash_table_mod2 (_Z15hash_table_mod2jj, funcdef_no=1065, decl_uid=33219, cgraph_uid=354, symbol_order=368)
But this suggests the actual table load differs?!
;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE26find_empty_slot_for_expa ndEj, funcdef_no=3327, decl_uid=112248, cgraph_uid=2446, symbol_order=2623) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE19find_slot_with_hashERKS2 _j13insert_option, funcdef_no=3056, decl_uid=112177, cgraph_uid=2175, symbol_order=2352) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=3048, decl_uid=112166, cgraph_uid=2167, symbol_order=2344) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE14find_w ith_hashERKS2_j, funcdef_no=2698, decl_uid=118471, cgraph_uid=1818, symbol_order=2019) ;; Function get_terminal_width (_Z18get_terminal_widthv, funcdef_no=1638, decl_uid=40874, cgraph_uid=752, symbol_order=778) ;; Function hash_table<indirect_string_hasher>::find_slot_with_hash (_ZN10hash_tableI22indirect_string_hasherLb0E11xcallocatorE19find_slot_with_h ashERKPKcj13insert_option, funcdef_no=3536, decl_uid=133145, cgraph_uid=2647, symbol_order=2952) ;; Function ggc_internal_cleared_alloc (_Z26ggc_internal_cleared_allocmPFvPvEmm, funcdef_no=1531, decl_uid=30171, cgraph_uid=670, symbol_order=708) ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833)
And these suggest the same - do we see the invocation count of ggc_internal_alloc and does that differ?
Yes, it is:
;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833) ... -Read edge from 0 to 2, count:1113521085 +Read edge from 0 to 2, count:1113521086
Huh. Difference by one :/
Read edge from 3 to 5, count:60717 Read edge from 4 to 5, count:14486906 -Read edge from 4 to 14, count:1098973462 +Read edge from 4 to 14, count:1098973463
The first edge is entry count. [...]
in the end most of the above could be secondary order effects by getting different profile for different generated code? We profile the stage2 compiler after all?
Is a different generated code expected? Yes, we profile stage2 compiler.
No, it's the bug that we generate different code ... but of course this would affect non-FDO, -fprofile-generate code then instead of -fprofile-use. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com