From patchwork Sat Jun 1 10:28:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 1108742 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-502137-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ucw.cz 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 45GHc36dCbz9sNR for ; Sat, 1 Jun 2019 20:29:01 +1000 (AEST) 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=KTGYrXefw7Gy2aZ0mk+k/ePpZW+gnaWe2Aw2CYdrkv2oGOYU6s0Yg 1PmvbkjQA0uaO2lWi20Zgjk6maggM6UAFKTz0boouFXoaggxhFfbtWE4QNVfJOeb XAurm4udRwM9YsyyPaVyX5iFWwiFfY/A0RdgzTvITkv77AvL8saaq0= 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=lsKBspZ35PUB5goJGFPWT0N9gas=; b=O8oDCLZOR00LWDpEQrGH /aB45wkyRn86T1CDDlK+RVEiYxRgbYIxk4dqmZB6QagEyJZwjoSBgqI/xVAZwkx3 pvC1CiFwwkTnjwZ0FGGkyvDV34j7IuVRictkYiPnH2ZpQrNTwmDx7aY6jrN6b5Qy bPqOMz1eNtutJjjPRyZ0sak= Received: (qmail 93514 invoked by alias); 1 Jun 2019 10:28:53 -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 93505 invoked by uid 89); 1 Jun 2019 10:28:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=sk:transla, H*Ad:U*rguenther, integer_type, disambiguate 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; Sat, 01 Jun 2019 10:28:50 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id C415028007A; Sat, 1 Jun 2019 12:28:42 +0200 (CEST) Date: Sat, 1 Jun 2019 12:28:42 +0200 From: Jan Hubicka To: rguenther@suse.de, d@dcepelik.cz, gcc-patches@gcc.gnu.org, jason@redhat.com Subject: Odd behaviour of indirect_ref_may_alias_decl_p in vn oracle Message-ID: <20190601102842.a5u4serztrf4omz7@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Hi, while looking for the reason for extra disambiguations in aliasing_component_refs I have noticed an odd case. We newly disambiguate: MEM[(Element_t *)_27 + 4B]; s.globalIDDataBase_m; unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff70fb5e8 precision:32 min max pointer_to_this > tree_0 tree_2 arg:0 public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 216 canonical-type 0x7ffff62df888> visited def_stmt _27 = &MEM[(struct OneDomain_t *)&s].D.113982.domain_m[i_26].D.110783.D.44395; version:27 ptr-info 0x7ffff5c66540> arg:1 constant 4>> unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7ffff494b7e0 fields context full-name "class GlobalIDDataBase" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > sizes-gimplified public unsigned type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 484 canonical-type 0x7ffff494bf18 pointer_to_this > arg:0 unit-size align:64 warn_if_not_align:0 symtab:0 alias-set 604 canonical-type 0x7ffff294d888 fields context full-name "class INode<3>" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this chain > tree_1 tree_2 arg:0 arg:0 > arg:1 > arg:1 used private unsigned nonlocal decl_3 DI /aux/hubicka/tramp3d-v4b.cpp:5583:21 size unit-size align:64 warn_if_not_align:0 offset_align 128 offset bit-offset context chain used private nonlocal decl_3 SI /aux/hubicka/tramp3d-v4b.cpp:5584:13 size unit-size align:32 warn_if_not_align:0 offset_align 128 offset bit-offset context chain >> /aux/hubicka/tramp3d-v4b.cpp:5457:24 start: /aux/hubicka/tramp3d-v4b.cpp:5457:24 finish: /aux/hubicka/tramp3d-v4b.cpp:5457:24> that did not make sense to me becaue ref1 type is integer_type and ref2 is pointer_type so these should be disambiguated by usual TBAA querry earlier. What happens is the following. The analysis happens via vn_reference_lookup which does if (! tbaa_p) r.ref_alias_set = r.base_alias_set = 0; later this is passed as ref1 but because it reffers to decl the order is exchanged so it appears as ref2 in in indirect_ref_may_alias_decl_p. Now there is test: /* If the alias set for a pointer access is zero all bets are off. */ if (base1_alias_set == 0) return true; which is ok, since base1_alias_set is non-0 (it is coming from indirect_ref). I think the code is not supposed to work this way :) I not convinced we realy want to give up on TBAA when ref is actual decl? At least polymorphic call analysis is using the assumption that placement news do not happen here. This patch fixes the odd case in conservative way and also reduces number of disambiguations noticeably: from aliasing_component_ref_p: 636 disambiguations, 15844 queries to aliasing_component_ref_p: 136 disambiguations, 13943 queries Can we construct valid placement new testcase where this matters? Honza * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Also give up TBAA path when base2_alias_set is 0. Index: tree-ssa-alias.c =================================================================== --- tree-ssa-alias.c (revision 271813) +++ tree-ssa-alias.c (working copy) @@ -1295,7 +1296,7 @@ indirect_ref_may_alias_decl_p (tree ref1 ptrtype1 = TREE_TYPE (TREE_OPERAND (base1, 1)); /* If the alias set for a pointer access is zero all bets are off. */ - if (base1_alias_set == 0) + if (base1_alias_set == 0 || base2_alias_set == 0) return true; /* When we are trying to disambiguate an access with a pointer dereference