From patchwork Thu Nov 7 13:10:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 1191142 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-512714-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="YeuuYIkz"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4783ff4G6Lz9sPk for ; Fri, 8 Nov 2019 00:10:16 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=LlwSpOALvizuuJGZe0vSW/BON3Hustuy/+Jjkxa+0dyAsZ1eCJwWl I4MzXmSFObg1hgsvL5uSyHT7UYyGfu4jaZ0K3TxARMs5CgodKDMnjBrqVwqeZ7do CTwbAX5ZHLu3eIw5ksrG/gddZQr/rInSyyxovBESfx31NWdEgWP6v8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=K5l2/gHNtz6AgLjYAiRxbRJTfMA=; b=YeuuYIkzRES4MH4YREmU LdYTFjDzoqLZp43oqmD+cFqAC3NKAqbeS2WuBoXN4WVhMCNigjmP9V7fYCSfjGFe w2VuoTc6xfiknuCWy3Z2W5uHGIILr+n8qiTKBdQT4PJ1HLTJXSk0EGqr/0vgiGnZ nOJ06amzrCn7trWAyn7IWyg= Received: (qmail 120312 invoked by alias); 7 Nov 2019 13:10:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 120299 invoked by uid 89); 7 Nov 2019 13:10:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS autolearn=ham version=3.3.1 spammy=277796, tree_binfo, 10k, 4335 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Nov 2019 13:10:06 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 57A4E282882; Thu, 7 Nov 2019 14:10:04 +0100 (CET) Date: Thu, 7 Nov 2019 14:10:04 +0100 From: Jan Hubicka To: gcc-patches@gcc.gnu.org, rguenther@suse.de Subject: Free some more stuff in free_lang_data Message-ID: <20191107131004.no4onem6qaw3xe3e@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Hi, as every year, I went through reasons why types of same ODR name are not merged in firefox streaming. Here are few problems I caught. Remaining issues I understand are 1) odr violations (which is OK of course) 2) keyed vtables: sometimes the vtable decl is weak and sometimes it is external (I have WIP patch for ipa-devirt to stream BINFO_VTABLE off the main stream, but at least for Firefox it does not have any dramatic effects on the size of stream) 3) differences in attribute list (some attributes, like aligned does not make sense on incomplete types, but our FEs lets us to add them there so I think there is no canonical incomplete variant here) 4) TYPELESS storage differences 5) if type is not merged also all types referring to it via TYPE_CONTEXT are not. This still causes propagation from type to another There are still some cases which I did not track down, but we have only couple hundred of unmerged types, so situation seems to be mostly under control. There is about 700MB of trees in global stream for Firefox + 200MB of in_decl_state vectors and I am not sure if there are easy ways to cut it down. Kind Nodes Bytes ---------------------------------------- constructors 12k 308k vecs 15k 1593k refs 55k 2702k binfos 63k 6670k constants 253k 9760k random kinds 654k 25M exprs 744k 23M identifiers 1217k 47M decls 1583k 293M types 1822k 298M ---------------------------------------- Total 6423k 709M ---------------------------------------- union_type 4335 real_cst 7244 mem_ref 8429 array_type 10k enumeral_type 10k constructor 12k tree_vec 15k array_ref 15k nop_expr 19k component_ref 30k pointer_plus_expr 41k tree_binfo 63k var_decl 78k function_type 106k integer_cst 110k reference_type 125k string_cst 132k type_decl 203k record_type 335k field_decl 355k method_type 583k pointer_type 642k tree_list 654k addr_expr 683k function_decl 941k identifier_node 1217k ---------------------------------------- Bootstrapped/regtested x86_64-linux, OK? Honza * tree.c (fld_incomplete_type_of): Clear TYPE_FINAL_P, TYPE_EMPTY_P, ENUM_IS_OPAQUE and ENUM_IS_SCOPED. (free_lang_data_in_binfo): Clear TREE_PUBLIC in BINFO (free_lang_data_in_type): Clear ENUM_IS_OPAQUE and ENUM_IS_SCOPED. Index: tree.c =================================================================== --- tree.c (revision 277796) +++ tree.c (working copy) @@ -5383,9 +5387,15 @@ fld_incomplete_type_of (tree t, class fr TYPE_TYPELESS_STORAGE (copy) = 0; TYPE_FIELDS (copy) = NULL; TYPE_BINFO (copy) = NULL; + TYPE_FINAL_P (copy) = 0; + TYPE_EMPTY_P (copy) = 0; } else - TYPE_VALUES (copy) = NULL; + { + TYPE_VALUES (copy) = NULL; + ENUM_IS_OPAQUE (copy) = 0; + ENUM_IS_SCOPED (copy) = 0; + } /* Build copy of TYPE_DECL in TYPE_NAME if necessary. This is needed for ODR violation warnings to come out right (we @@ -5468,6 +5478,7 @@ free_lang_data_in_binfo (tree binfo) BINFO_INHERITANCE_CHAIN (binfo) = NULL_TREE; BINFO_SUBVTT_INDEX (binfo) = NULL_TREE; BINFO_VPTR_FIELD (binfo) = NULL_TREE; + TREE_PUBLIC (binfo) = 0; FOR_EACH_VEC_ELT (*BINFO_BASE_BINFOS (binfo), i, t) free_lang_data_in_binfo (t); @@ -5569,6 +5580,8 @@ free_lang_data_in_type (tree type, class { if (TREE_CODE (type) == ENUMERAL_TYPE) { + ENUM_IS_OPAQUE (type) = 0; + ENUM_IS_SCOPED (type) = 0; /* Type values are used only for C++ ODR checking. Drop them for all type variants and non-ODR types. For ODR types the data is freed in free_odr_warning_data. */