[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2021-11-16 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Bug 83665 depends on bug 79224, which changed state. Bug 79224 Summary: [7 Regression] Large C-Ray slowdown https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 What|Removed |Added

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-03-27 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #18 from Pat Haugen --- (In reply to Richard Biener from comment #17) > Pat, please open a new bug for the regression caused by the fix. Done, pr85103.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-03-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-03-26 Thread pthaugen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Pat Haugen changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-03-19 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #15 from Martin Liška --- Honza, may I close this as fixed?

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-02-12 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #14 from Jan Hubicka --- Author: hubicka Date: Mon Feb 12 09:48:06 2018 New Revision: 257582 URL: https://gcc.gnu.org/viewcvs?rev=257582=gcc=rev Log: PR middle-end/83665 * params.def (inline-min-speedup): Increase

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-02-01 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #13 from Jan Hubicka --- I have started with experiments on czerny. Set --param inline-min-speedup from 8 to 15 at 30th of January and to 30 yesterday. Most of size regression comes away with 15 and I observed to off-noise

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-30 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #12 from rguenther at suse dot de --- On Tue, 30 Jan 2018, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 > > --- Comment #11 from Jan Hubicka --- > Yes, I have started experiments with

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-30 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #11 from Jan Hubicka --- Yes, I have started experiments with adjusting inliner limits: hopefully we can tune up speedup limit because it is now applied more agresively (due to lack of capping) and perhaps tune down size limits

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #10 from Richard Biener --- Unsure what to do about this bug -- things have gone back a bit but as you say the cap introduced artificial limit back in times. But we do have large-function-growth to limit big_speedup for large

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-08 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-08 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #8 from rguenther at suse dot de --- On Mon, 8 Jan 2018, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 > > --- Comment #6 from Martin Liška --- > Ok, for the gromacs > > r255102: .text

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-08 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #7 from Martin Liška --- Another experiment: r255024: 741B r255024 + patch r255103 + patch r256072: 752B

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-08 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #6 from Martin Liška --- Ok, for the gromacs r255102: .text size: 737B r255103 + fix for sreal (r256072): .text size: 752B (+2.03%). Honza can you please take a look?

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-05 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #5 from Richard Biener --- Bisection of one or another example with the big_speedup_p fix manually patched in would be appreciated I guess.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-04 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #4 from Martin Liška --- I see change in r256072 that increased .text in gromacs from: 83.6% 743Ki .text 743Ki 14.4% to 83.8% 760Ki .text 760Ki 14.4%

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-04 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Markus Trippelsdorf changed: What|Removed |Added Target Milestone|--- |8.0

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-04 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Markus Trippelsdorf changed: What|Removed |Added Keywords||needs-bisection

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-03 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #2 from Jan Hubicka --- One potential candidate is the ipa-inline big_speedup_p fix by Richard. It does not seem to explain all the difference though. I have quickly checked that it does affect gzip LTO binary, but less than

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

2018-01-03 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org ---