From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100452 invoked by alias); 23 Feb 2018 20:49:45 -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 100427 invoked by uid 89); 23 Feb 2018 20:49:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:2039 X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Feb 2018 20:49:44 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9E8CF40FB658 for ; Fri, 23 Feb 2018 20:49:32 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-85.brq.redhat.com [10.40.204.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7028C2026E03 for ; Fri, 23 Feb 2018 20:49:31 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w1NH6soQ022713; Fri, 23 Feb 2018 18:06:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w1NH6pxq022712; Fri, 23 Feb 2018 18:06:51 +0100 Date: Fri, 23 Feb 2018 20:49:00 -0000 From: Jakub Jelinek To: Richard Biener , Jeff Law , Jan Hubicka , Martin Jambor Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix up ipa_vr_ggc_hash_traits::hash Message-ID: <20180223170651.GE5867@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg01353.txt.bz2 Hi! ipa_vr_ggc_hash_traits::equal does return a->type == b->type && a->min == b->min && a->max == b->max; so it requires pointer identical type (5 value enum) and min/max, hopefully only INTEGER_CSTs. Honza complained on IRC that during firefox a lot of time is spent in this hash table, probably because the hash function was poor, it hashes any ranges with the same min/max values but different TREE_TYPE (p->min) the same. The following patch adjusts the hash method to match the equal method, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? In theory we could get bigger savings by e.g. using operand_equal_p on p->min and p->max instead of pointer comparison, but not really sure if the VRP code is prepared for that. E.g. VRP cares whether min or max are the minimum or maximum of the corresponding type, but if we ignore the type completely, it could be any other integral type. We'd use the same value_range memory struct for unsigned char [5, 255] range, where it is [5, +INF] and for int, where it is just [5, 255]. Does LTO canonicalize INTEGER_TYPEs using type_hash_canon? In any case, I think further optimizations should be postponed for GCC9. 2018-02-23 Jakub Jelinek * ipa-prop.c (ipa_vr_ggc_hash_traits::hash): Hash p->min and p->max as pointers rather than using iterative_hash_expr. --- gcc/ipa-prop.c.jj 2018-01-03 10:19:54.617533871 +0100 +++ gcc/ipa-prop.c 2018-02-23 14:43:08.983733102 +0100 @@ -111,12 +111,13 @@ struct ipa_vr_ggc_hash_traits : public g typedef value_range *compare_type; static hashval_t hash (const value_range *p) - { - gcc_checking_assert (!p->equiv); - hashval_t t = (hashval_t) p->type; - t = iterative_hash_expr (p->min, t); - return iterative_hash_expr (p->max, t); - } + { + gcc_checking_assert (!p->equiv); + inchash::hash hstate (p->type); + hstate.add_ptr (p->min); + hstate.add_ptr (p->max); + return hstate.end (); + } static bool equal (const value_range *a, const value_range *b) { Jakub