[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 Martin Liška changed: What|Removed |Added Summary|[12 Regression] |[12 Regression] |compile-time regressions|compile-time regressions |with generic tuning |with generic tuning since ||r12-7756-g27d8748df59fe6 --- Comment #3 from Martin Liška --- Started with r12-7756-g27d8748df59fe6, one can see it also with x86_64-linux-gnu cross compiler: $ ./xg++ -B. cactu.ii -c -Ofast $ ./xg++ -v ... Configured with: /home/marxin/Programming/gcc2/configure --enable-languages=c,c++ --prefix=/home/marxin/bin/gcc --disable-multilib --disable-libsanitizer --disable-bootstrap --target=aarch64-linux-gnu --enable-checking=release
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #4 from Martin Liška --- Created attachment 52760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52760&action=edit Test-case
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 Martin Liška changed: What|Removed |Added CC||avieira at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org --- Comment #5 from Martin Liška --- Good revision: $ time ./xg++ -B. /home/marxin/Programming/testcases/cactu.ii -S -Ofast real0m12.084s user0m11.892s sys 0m0.192s 14.49% cc1plus cc1plus [.] find_hard_regno_for_1 5.68% cc1plus cc1plus [.] find_base_term 3.83% cc1plus cc1plus [.] bitmap_clear_bit 2.98% cc1plus cc1plus [.] bitmap_set_bit 2.57% cc1plus libc.so.6 [.] __memset_avx2_unaligned_erms 2.51% cc1plus cc1plus [.] build_object_conflicts 2.47% cc1plus cc1plus [.] rtx_equal_for_memref_p Bad revision: $ time ./xg++ -B. /home/marxin/Programming/testcases/cactu.ii -S -Ofast real0m17.969s user0m17.772s sys 0m0.196s 16.92% cc1plus cc1plus [.] find_hard_regno_for_1 8.67% cc1plus cc1plus [.] find_base_term 4.26% cc1plus cc1plus [.] rtx_equal_for_memref_p 3.85% cc1plus cc1plus [.] memrefs_conflict_p 2.92% cc1plus cc1plus [.] find_base_term 2.74% cc1plus cc1plus [.] build_object_conflicts 2.67% cc1plus cc1plus [.] true_dependence_1
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #6 from Richard Biener --- More to the point the cited rev. doesn't look like it should change anything for -mtune=generic. Maybe the "generic" config is always the last one on aarch64 and now "demeter"? At least there doesn't seem to be explicit "generic" configs like on x86_64.
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #7 from Tamar Christina --- (In reply to Richard Biener from comment #6) > More to the point the cited rev. doesn't look like it should change anything > for -mtune=generic. Maybe the "generic" config is always the last one on > aarch64 and now "demeter"? At least there doesn't seem to be explicit > "generic" configs like on x86_64. We do have an explicit generic tuning struct, the ones with generic_* in the name e.g. generic_tunings, but as you say, this patch doesn't change it at all. we'll take a look.
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #8 from Richard Biener --- Most of the compile-time is spent in scheduling, so I think the scheduling model was somehow exchanged.
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #9 from avieira at gcc dot gnu.org --- Found the issue, it's due to the way we encode TARGET_CPU_DEFAULT in aarch64, it is only able to support 64 cores and we have 65 now. Testing a work around for now and we have plans to fix this properly in GCC 13.
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 --- Comment #10 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:5522dec054cb940fe83661b96249aa12c54c1d77 commit r12-8060-g5522dec054cb940fe83661b96249aa12c54c1d77 Author: Andre Vieira Date: Fri Apr 8 15:12:23 2022 +0100 aarch64: PR target/105157 Increase number of cores TARGET_CPU_DEFAULT can encode This addresses the compile-time increase seen in the PR target/105157. This was being caused by selecting the wrong core tuning, as when we added the latest AArch64 the TARGET_CPU_generic tuning was pushed beyond the 0x3f mask we used to encode both target cpu and attributes into TARGET_CPU_DEFAULT. gcc/ChangeLog: PR target/105157 * config.gcc: Shift ext_mask by TARGET_CPU_NBITS. * config/aarch64/aarch64.h (TARGET_CPU_NBITS): New macro. (TARGET_CPU_MASK): Likewise. (TARGET_CPU_DEFAULT): Use TARGET_CPU_NBITS. * config/aarch64/aarch64.cc (aarch64_get_tune_cpu): Use TARGET_CPU_MASK. (aarch64_get_arch): Likewise. (aarch64_override_options): Use TARGET_CPU_NBITS.
[Bug target/105157] [12 Regression] compile-time regressions with generic tuning since r12-7756-g27d8748df59fe6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157 avieira at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from avieira at gcc dot gnu.org --- The commit above should have fixed the issue. Let me know if you still observe the higher compile-time in your nightlies.
