[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Jambor --- And fixed on the gcc-8-branch too.
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Marc Glisse changed: What|Removed |Added Summary|[8/9 Regression] Larger |[8 Regression] Larger code |code generated from GMP |generated from GMP template |template meta-programming |meta-programming --- Comment #11 from Marc Glisse --- Seems fixed on trunk.
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Marc Glisse changed: What|Removed |Added Attachment #43982|0 |1 is obsolete|| --- Comment #3 from Marc Glisse --- Created attachment 43985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43985&action=edit preprocessed testcase (slightly reduced, compiles with -fno-exceptions)
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 --- Comment #2 from Marc Glisse --- (In reply to Jakub Jelinek from comment #1) > I think this is a result of many changes. > E.g. r249885 bumps .s size from 3709 to 4599 bytes, r254724 from 4599 to > 5768, r255510 from 5772 to 7713. You are compiling with -O3, not -Os, so > the size is not what counts though, but the code speed, right? -Os gives something much larger (16633). I agree 100% that what matters at -O3 is code speed, not size, and I am only using the size as a crude indicator before looking into the code more closely. And what I saw were many extra moves and some missed __builtin_constant_p opportunities, both of which obviously have a negative impact on performance. If the only size increase came from outlining the exception code, that would be fine. But compiling with -fno-exceptions (after removing enough exception-related unnecessary stuff from the file so it compiles) still shows an increase from 2639 to 4268.
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |8.0
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think this is a result of many changes. E.g. r249885 bumps .s size from 3709 to 4599 bytes, r254724 from 4599 to 5768, r255510 from 5772 to 7713. You are compiling with -O3, not -Os, so the size is not what counts though, but the code speed, right?