From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32593 invoked by alias); 13 Jun 2012 19:51:49 -0000 Received: (qmail 32584 invoked by uid 22791); 13 Jun 2012 19:51:48 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jun 2012 19:51:36 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SetbK-0004oF-7h from Sandra_Loosemore@mentor.com ; Wed, 13 Jun 2012 12:51:34 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 12:50:58 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Wed, 13 Jun 2012 12:51:33 -0700 Message-ID: <4FD8EF66.4020506@codesourcery.com> Date: Wed, 13 Jun 2012 19:57:00 -0000 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Richard Guenther CC: , Zdenek Dvorak Subject: Re: [RFC, ivopts] fix bugs in ivopts address cost computation References: <4FCE3512.7070607@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-06/txt/msg00863.txt.bz2 On 06/06/2012 02:29 AM, Richard Guenther wrote: > > Pre-computing and caching things is to avoid creating RTXen over and over. > As you have discarded this completely did you try to measure the cost > of doing so in terms of produced garbage and compile-time cost? Did you > consider changing the target interface of IVOPTs to a (bunch of) new > target hooks that avoid the RTX generation (which in fact we are not sure > that we'll end up producing anyways in exactly that form due to subsequent > optimizations)? Since there seemed to be resistance to removing the pre-computing of costs, I've spent much of the last week trying to glue fixes on the existing code while preserving the caching, and just am not happy with the result. It makes the code too complicated, adds additional overhead by precomputing more things, and still does not fix the lurking bugs WRT differing costs for different values of constant offsets and the like. Basically, I don't want to put my name on anything that ugly. :-P So, I went back and did some compile time benchmarking on my previously posted patch instead. I used the bzip2 and gcc test programs available here: http://people.csail.mit.edu/smcc/projects/single-file-programs/ These are respectively large and gigantic single-file programs, so you would expect the performance effects of caching to be particularly evident here as there would likely be many loops involving the same modes in each compilation unit. I compiled them using a native x86_64 build with "time gcc -c -O3", and ran each set of timings 3 times with an unmodified build and with my previously-posted patch. And, it turns out there is no obvious difference in the results. bzip2 base: 5.82, 5.82, 5.75 bzip2 patched: 5.73, 5.71, 5.85 gcc base: 4m44.390, 4m44.270, 4m44.060 gcc patched: 4m44.210, 4m44.530, 4m44.040 > Can you split the patch into pieces fixing the above bugs separately? > Removing the pre-compute and caching is the most questionable change, > the others look like real bugs (the symbol cost might be questionable as > well). Given that most of the bugs were in the same function and were fixed by rewriting it completely, trying to split up the patch seems kind of pointless, to me. > CC-ing Zdenek for his opinions (disclaimer: I didn't look at the actual patch). Might somebody be willing to review the patch as posted? FWIW, I was doing some digging around in the mail archives to see if there was any discussion that would help me understand the rationale for the current cost model better. What I found was that when the ivopts pass was originally added back in 2004, the costs computation was one of the things that was specifically mentioned as needing work at least to document it better, but the patch was rushed through and approved without any thorough review because the Stage 3 deadline was looming. Anyway, given that get_address_cost has had a big FIXME on it all these years, it seems to me like maybe it's time to try to fix it? -Sandra