From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13561 invoked by alias); 26 Nov 2016 18:08:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13531 invoked by uid 89); 26 Nov 2016 18:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=*before*, quality, H*r:8.13.8 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 26 Nov 2016 18:08:15 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id uAQI8AAS029053; Sat, 26 Nov 2016 12:08:11 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id uAQI89mQ029050; Sat, 26 Nov 2016 12:08:09 -0600 Date: Sat, 26 Nov 2016 18:08:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Bernd Schmidt , GCC Patches Subject: Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386. Message-ID: <20161126180807.GA28017@gate.crashing.org> References: <2bde94e0-b470-8aad-6a9c-91e45dc8b687@redhat.com> <20161124142119.GD14394@gate.crashing.org> <165a4b5a-86f3-4b0c-a2fe-dd5a40ef4f08@redhat.com> <20161124143632.GE14394@gate.crashing.org> <1cd79d19-c745-c3e6-10ca-a53709e35e09@redhat.com> <20161124145354.GF14394@gate.crashing.org> <3fbcaeeb-7855-82c8-8380-de893c08735e@redhat.com> <20161124161423.GG14394@gate.crashing.org> <20161124223241.GA30675@gate.crashing.org> <1026ad63-e814-6f70-2006-a7b0098e305f@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1026ad63-e814-6f70-2006-a7b0098e305f@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg02692.txt.bz2 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