From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24956 invoked by alias); 19 Aug 2015 08:55:23 -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 24034 invoked by uid 89); 19 Aug 2015 08:55:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-SHA encrypted) ESMTPS; Wed, 19 Aug 2015 08:55:21 +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 t7J8tH4i009178; Wed, 19 Aug 2015 03:55:17 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t7J8tHZs009177; Wed, 19 Aug 2015 03:55:17 -0500 Date: Wed, 19 Aug 2015 08:56:00 -0000 From: Segher Boessenkool To: "Bin.Cheng" Cc: gcc-patches List Subject: Re: [PATCH] ivopts costs debug Message-ID: <20150819085516.GA8652@gate.crashing.org> References: <9f6de433cd9a44841992b7ac3eebc6106e3c3e7e.1439931648.git.segher@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01051.txt.bz2 On Wed, Aug 19, 2015 at 10:45:42AM +0800, Bin.Cheng wrote: > I ran into back-end address cost issue before and this should be > useful in such cases. Though there are a lot of dumps, it would be > better to classify it into existing dump option (TDF_DETAILS?) and > discard the use of macro. But TDF_DETAILS is enabled pretty much always, and this costs dump isn't to debug ivopts _itself_. I got the idea from lower-subreg.c, which also uses debug macros like this (and is another place where bad costs tend to show up, btw). > Also the address cost will be tuned/dumped > later, we should differentiate between them by emphasizing this part > of dump is the original cost from back-end. Yeah I should probably print some header, also say e.g. what machine mode some table is for. > > It also shows that the LAST_VIRTUAL_REGISTER trickery ivopts does > > does not work (legitimize_address can create new registers, so now > > a) we have new registers anyway, and b) we use some for multiple > > purposes. Oops). > Yes, that makes seq dump a little weird. It can even make the result wrong -- e.g. (plus (reg 155) (reg 155)) could well be costed differently than (plus (reg 155) (reg 159)). Segher