From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18922 invoked by alias); 14 Feb 2014 00:48:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18909 invoked by uid 89); 14 Feb 2014 00:48:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 14 Feb 2014 00:48:31 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 7BF24541B8B; Fri, 14 Feb 2014 01:48:27 +0100 (CET) Date: Fri, 14 Feb 2014 00:48:00 -0000 From: Jan Hubicka To: gcc@gcc.gnu.org, rguenther@suse.de, jason@redhat.com Subject: TYPE_BINFO and canonical types at LTO Message-ID: <20140214004827.GA30858@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-02/txt/msg00190.txt.bz2 Hi, I have noticed that record_component_aliases is called during LTO time and it examines contents of BINFO: 0x5cd7a5 record_component_aliases(tree_node*) ../../gcc/alias.c:1005 0x5cd4a9 get_alias_set(tree_node*) ../../gcc/alias.c:895 0x5cc67a component_uses_parent_alias_set_from(tree_node const*) ../../gcc/alias.c:548 0x5ccc42 reference_alias_ptr_type_1 ../../gcc/alias.c:660 0x5ccf93 get_alias_set(tree_node*) ../../gcc/alias.c:740 0xb823d8 indirect_refs_may_alias_p ../../gcc/tree-ssa-alias.c:1125 0xb82d8d refs_may_alias_p_1(ao_ref*, ao_ref*, bool) ../../gcc/tree-ssa-alias.c:1279 0xb848df stmt_may_clobber_ref_p_1(gimple_statement_base*, ao_ref*) ../../gcc/tree-ssa-alias.c:2013 0xb85d27 walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*, tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*), void*) ../../gcc/tree-ssa-alias.c:2411 0xc509f3 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**) ../../gcc/tree-ssa-sccvn.c:2063 0xc52ea4 visit_reference_op_store ../../gcc/tree-ssa-sccvn.c:2970 0xc55404 extract_and_process_scc_for_name ../../gcc/tree-ssa-sccvn.c:3825 This smells bad, since it is given a canonical type that is after the structural equivalency merging that ignores BINFOs, so it may be completely different class with completely different bases than the original. Bases are structuraly merged, too and may be exchanged for normal fields because DECL_ARTIFICIAL (that separate bases and fields) does not seem to be part of the canonical type definition in LTO. I wonder if that code is needed after all: case QUAL_UNION_TYPE: /* Recursively record aliases for the base classes, if there are any. */ if (TYPE_BINFO (type)) { int i; tree binfo, base_binfo; for (binfo = TYPE_BINFO (type), i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++) record_alias_subset (superset, get_alias_set (BINFO_TYPE (base_binfo))); } for (field = TYPE_FIELDS (type); field != 0; field = DECL_CHAIN (field)) if (TREE_CODE (field) == FIELD_DECL && !DECL_NONADDRESSABLE_P (field)) record_alias_subset (superset, get_alias_set (TREE_TYPE (field))); break; all bases are also fields of within the type, so the second loop should notice all the types seen by first loop if I am correct? So perhaps the loop can be dropped at first place. Honza