From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69763 invoked by alias); 3 Nov 2019 18:17:19 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 69754 invoked by uid 89); 3 Nov 2019 18:17:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=Someone, regressed 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; Sun, 03 Nov 2019 18:17:18 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id xA3IHESt002286; Sun, 3 Nov 2019 12:17:15 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xA3IHDX8002285; Sun, 3 Nov 2019 12:17:13 -0600 Date: Sun, 03 Nov 2019 18:17:00 -0000 From: Segher Boessenkool To: Oleg Endo Cc: David Brown , Jeff Law , Mikael Tillenius , gcc-help@gcc.gnu.org Subject: Re: Non-optimal code generated for H8 Message-ID: <20191103181713.GA16031@gate.crashing.org> References: <5b46f0b2-6ded-784c-00ff-fe592819b397@tillenius.com> <13ffbba6-2b7b-f3b3-9b7a-20923b8271cc@redhat.com> <20191030003455.GI28442@gate.crashing.org> <064d14f9-7fb5-5fa0-8992-521c52907931@westcontrol.com> <20191030224902.GR28442@gate.crashing.org> <5f01a3770e94cb070ac43d5ed45709ac897d1694.camel@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f01a3770e94cb070ac43d5ed45709ac897d1694.camel@t-online.de> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00006.txt.bz2 Hi! On Sun, Nov 03, 2019 at 09:24:17PM +0900, Oleg Endo wrote: > On Wed, 2019-10-30 at 17:49 -0500, Segher Boessenkool wrote: > > But if you have no time to waste, -Os usually give you smaller code than > > -O2, even if some of the choices on the size <-> speed tradeoff are a bit > > questionable (bug reports or patches welcome, of course!) And sometimes > > -Os is unavoidably a bit bigger than -O2, it just sets *heuristics* after > > all. But if you see this often (for some specific target?), please file > > a PR for that as well. > > I've got at least one MCU project which needs to fit into certain > amount of ROM. As long as it stays within that limit, anything is > fine. Each time I updated the compiler, starting from GCC 6, then 7 > and finally on GCC 8, there were issues with the code size -- the > compiled output just kept getting bigger and bigger. At some point I > even had to roll my own GCC patch to reverse one of the changes to the > heuristics in some place. But the need for that was only temporary. > > How to report this kind of regression as a PR? Obviously I can't > attach the full source code and build system and whatnot (which is not > open source to begin with). And for the same reason, trying to extract > a reproducer also seems too time consuming and not feasible. > > Any ideas, suggestions or strategies how to report these kinds of > problems? You can still report it, of course. Someone might have an idea what causes it, esp. if you give enough info. It also helps if you can at least partially bisect it, find when the problem was introduced. It also helps a lot if you know the area in the compiler that regressed, or have a motivated guess for that anyway :-) Segher