On Sat, Nov 26, 2016 at 03:44:22AM -0700, Jeff Law wrote: > On 11/24/2016 03:32 PM, Segher Boessenkool wrote: > >On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote: > >>On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: > >>>On 11/24/2016 07:53 AM, Segher Boessenkool wrote: > >>>> > >>>>That we compare different kinds of costs (which really has no meaning at > >>>>all, it's a heuristic at best) in various places is a known problem, not > >>>>a regression. > >>>But the problems with the costing system exhibit themselves as a code > >>>quality regression. In the end that's what the end-users see -- a > >>>regression in the quality of the code GCC generates. > >> > >>Yes, exactly -- and I fear this all-encompassing change will cause just > >>such a regression for many users. Tests are running, will know more > >>later today (or tomorrow). > >> > >>The PR is about a very specific problem; the patch is not. The patch > >>is not a bug fix. If we allow anything that "makes things better" in > >>stage 3, what make it different from stage 1 then? > > > >Here are results of testing with trunk right before the three patches, > >compared with with the three patches. This lists the sizes of the vmlinux > >of a Linux kernel build for that arch. > Thanks. While I question how much emphasis we should put on code sizes > as a way to measure this change, it can still point out interesting > effects, positive and negative.
Code size I can test "easily" for many archs (it still takes almost a full day), and it does correlate well with local optimisations on most archs. I have looked at the actual differences on some archs (which takes a lot more time still), and the differences are all over the place. Which suggests changing the costs is a big change for most of those archs; and they all have been tuned for the *old* situation, so this makes things worse in the short run, whether the new costs are better or not. Not a change for stage 3, and not something *I* should need to analyse anyway; this analysis needs to be done *before* the patch goes in. > From my investigations on the m68k, the effects on the IL are minimal > with a slight bias towards better code (by suppressing if-conversions of > some now more costly blocks). *But* the size of the resulting code was > all over the place -- sometimes it was better, others worse. From > looking at the assembly we seemingly are copying blocks that aren't > strictly necessary. > > Enter bb-reorder and the STC algorithm. It is copying blocks *very* > aggressively, like absurdly aggressively on the m68k. Of course it > doesn't help that the m68k doesn't define a length attribute and as a > result STC thinks every insn has size 0 and thus block copying is zero cost. > > I want to verify the #s, so take this with a slight grain of salt. The > net changes to newlib's .o's for Bernd's work -- +30 bytes. The effect > of the STC issue above -- +1115586 bytes. Or to put it another way, > Bernd's changes, +.0003% change. STC, +13.8%. STC wasn't changed in the patch. Maybe interactions with STC is what causes all the problems, but that is an argument *against* doing this after stage 1. Segher
