From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46395 invoked by alias); 26 Oct 2018 17:49:30 -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 45661 invoked by uid 89); 26 Oct 2018 17:48:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=prs, PRs, opened, HContent-Transfer-Encoding:8bit 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; Fri, 26 Oct 2018 17:48:28 +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 w9QGm9Gh012441; Fri, 26 Oct 2018 11:48:10 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id w9QGm7UT012432; Fri, 26 Oct 2018 11:48:07 -0500 Date: Fri, 26 Oct 2018 18:37:00 -0000 From: Segher Boessenkool To: Steve Ellcey Cc: Andreas Schwab , "gcc-patches@gcc.gnu.org" , "bergner@linux.ibm.com" Subject: Re: [PATCH] combine: Do not combine moves from hard registers Message-ID: <20181026164805.GN5205@gate.crashing.org> References: <1540571945.12895.67.camel@cavium.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1540571945.12895.67.camel@cavium.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01732.txt.bz2 On Fri, Oct 26, 2018 at 04:39:06PM +0000, Steve Ellcey wrote: > What is the status of this patch?  I see PR 87708, which is for the > regression to ira-shrinkwrap-prep-[12].c but what about all the > other regressions?  I see 27 of them on my aarch64 build and when > I looked at one of them (gcc.target/aarch64/cvtf_1.c) the code looks > worse than before, generating an extra instruction in each of the > routines.  Here is an example from one function where there is an > extra fmov that was not there before.  The test runs at -O1 but > the extra instruction appears at all optimization levels.  Should > I submit a new PR for this? Yes, please open a PR. It's hard to keep track of things without. Status: I have figure out what I am doing wrong, I hope to have a patch soon. This will not fix all the register allocation problems of course. It's a pity no PRs are opened for the code improvements either though ;-) Segher