From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20003 invoked by alias); 28 Oct 2011 06:25:10 -0000 Received: (qmail 19965 invoked by uid 22791); 28 Oct 2011 06:25:08 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 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; Fri, 28 Oct 2011 06:24:52 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RJfs3-0007M6-B2 from Maxim_Kuvyrkov@mentor.com ; Thu, 27 Oct 2011 23:24:51 -0700 Received: from [127.0.0.1] ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2011 07:24:49 +0100 Subject: Re: [PATCH] Distribute inliner's size_time data across entries with similar predicates Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Maxim Kuvyrkov In-Reply-To: <20111020093244.GC30227@atrey.karlin.mff.cuni.cz> Date: Fri, 28 Oct 2011 08:22:00 -0000 Cc: gcc-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111020093244.GC30227@atrey.karlin.mff.cuni.cz> To: Jan Hubicka 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: 2011-10/txt/msg02620.txt.bz2 On 20/10/2011, at 10:32 PM, Jan Hubicka wrote: > Hi, >> Jan, >>=20 >> The following patch started as a one-liner for ipa-inline-analysis.c: ac= count_size_time() to merge predicates when we are adding data to entry[0] (= i.e., when space for 32 size_time entries is exhausted): >>=20 >> @@ -537,6 +592,9 @@ account_size_time (struct inline_summary >> } >> else >> { >> + e->predicate =3D or_predicates (summary->conds, &e->predicate, pr= ed); >> e->size +=3D size; >> e->time +=3D time; >> if (e->time > MAX_TIME * INLINE_TIME_SCALE) >=20 > As we discussed, this is not needed in current form because we arrange fi= rst predicate to be always > true and thus we could always place there all the costs that did not fit = elwhere. >=20 > The patch has a problem with fact that the predicates must be always cons= ervative i.e. when > they are proved to be false the code must be unreachable after inlining. I don't understand your point. The OR-ing of the predicates allows us to m= erge size_time_entries and keep the total number of them under a desired li= mit. Currently all merging goes into entry[0], and the patch makes the ext= ra information to get distributed across more entries. Because we OR the p= redicates, we keep the information conservative; now in order to say that c= ertain code will be unreachable the inliner has to prove to be false the OR= -ed predicate. Now, one can argue whether it is actually a benefit to distribute the infor= mation more evenly and, consequently, making more predicates harder to disp= rove. In current scheme we have the surplus of size_time information under= one impossible-to-disprove predicate and many entries with easier-to-dispr= ove-predicates. My patch changes the situation to having most of the size_= time information in entries with harder-but-possible-to-disprove predicates. Am I missing something? >=20 > We could either go with your patch with the distance fuction modified to = accept > only predicates such that the new predicate is implied by them. If you a= re > willing to play with this, I have no problem with going for this. Yes, favoring predicates that already imply the new one is a good suggestio= n. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics