From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58315 invoked by alias); 19 Sep 2019 11:30:25 -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 58300 invoked by uid 89); 19 Sep 2019 11:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=richi, honza, Richi, Honza X-HELO: mail-lf1-f67.google.com Received: from mail-lf1-f67.google.com (HELO mail-lf1-f67.google.com) (209.85.167.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 11:30:22 +0000 Received: by mail-lf1-f67.google.com with SMTP id q11so2065948lfc.11 for ; Thu, 19 Sep 2019 04:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H4WpkJOQ0cRThL9MlyJOp/wZS3zk73iwnT8WUUiKcvk=; b=SGtqoQGKDP3/qEznOOJtX/4EG8mJGnqkjvK4XbsS+IqcMjeu/c10hizSjFQwuglCEI 2/VzrQAwfnWeRzulzG2UWmLeC3kNWqlgbRGLzQ5IsByBZV4U4eRd1poGDbrvp5lv87p1 832b9pA+toyEWkmg2SMyX7Rj9HaBl8+qTtXT6UtfBuQtCG3Babq0DTPp2R05Rie2PDJy JgceH81PI5BYN2Nnx9o+VJH3fceamBKXmBgez8tacxeFlx+/ySDz2g09tWonKu8vcsxO QtrOHwQBQaUSEgUi4tNm/57C23tR2697ByQvHPVm2n8NwrxC75G/E8StltC1DqwOQZDt wNgw== MIME-Version: 1.0 References: <24e91baf28c01421ba05c877e00c058a2008a5cc.1565105736.git.mliska@suse.cz> <430c1435-a4c9-2960-5542-b95a8c346744@suse.cz> <11eca972-aa61-0ffa-04c1-5f42dbb9d32d@suse.cz> <2f56762b-fc0b-dece-e2af-d9d50d0e2a24@suse.cz> <0e926714-f378-8df0-c8d0-500277b49abc@suse.cz> In-Reply-To: <0e926714-f378-8df0-c8d0-500277b49abc@suse.cz> From: Richard Biener Date: Thu, 19 Sep 2019 11:30:00 -0000 Message-ID: Subject: Re: [PATCH 5/9] Come up with an abstraction. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Michael Matz , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg01153.txt.bz2 On Wed, Sep 18, 2019 at 9:56 AM Martin Li=C5=A1ka wrote: > > Hello. > > Ok, so the current IPA ICF transformation is being blocked by the > patch 2/9 (about FIELD_DECL). I asked Honza for a help here. > In the meantime, can you Richi make an opinion about the part 5 which > is about the interaction in between old operand_equal_p and a new > hook in IPA ICF? +static operand_compare default_compare_instance; + +/* Conveinece wrapper around operand_compare class because usually we do + not need to play with the valueizer. */ + +bool +operand_equal_p (const_tree arg0, const_tree arg1, unsigned int flags) +{ + return default_compare_instance.operand_equal_p (arg0, arg1, flags); +} can we devirtualize this and thus further clone and devirtualize the recursions in the default instance? if not does making the default instance const help (you need to make the methods const, possibly a good idea if that works for your ICF use as well?) + if (flag_checking && !(flags & OEP_NO_HASH_CHECK)) + { better keep that in the caller (avoids the virtual call and also then the function does what it says...). Otherwise it looks OK. Note I'd really like to see the overhead for the regular operand_equal_p calls being zero, thus devirt is important here - but it should work with IPA-CP of 'this'? But maybe the function is too big to clone :/ Richard. > Thanks, > Martin