From patchwork Mon May 6 12:28:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 1095803 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-500152-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="DNhBaRDi"; 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 44yMV22Fb0z9s7T for ; Mon, 6 May 2019 22:28:40 +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=PNtG5AQOBroM0TfnekYtT8rFUCIqoHyyRH2Sx93xVr5wQCTEJwHbX KVUJRmhxiX30JH+s3mjNgNqk5ssdIA1YEdp752o0WN5uRbSWI6Tg56TUGYOtEhV8 IZ1C30C13OcOxuNUkoyQ+v2v1cJ3VRosH4iurhptTVfEcrji8zX63M= 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=8mMpbMitHC8TgaULfd3Z4pHiZns=; b=DNhBaRDiYPoJYsAFpCkT usp0J2QTpkDZDiTvgicEhJhjqvIfnx/wO/q4keB99fkBp3DnY0LtYV5P6y2DF2SG BQXIcXCFvH5cFSueuMEFfiQb2nIzTEINM7uwQuIiAOoMBsW3CS6YWWIeumf/ALlF x9k2bIx49nRGw4QhmNP5jVU= Received: (qmail 67691 invoked by alias); 6 May 2019 12:28:33 -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 67682 invoked by uid 89); 6 May 2019 12:28:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=organized, TYPE_CANONICAL, type_canonical, bail 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; Mon, 06 May 2019 12:28:30 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 3FC0B280586; Mon, 6 May 2019 14:28:28 +0200 (CEST) Date: Mon, 6 May 2019 14:28:28 +0200 From: Jan Hubicka To: d@dcepelik.cz, rguenther@suse.de, gcc-patches@gcc.gnu.org Subject: aliasing_component_refs_p tweek Message-ID: <20190506122828.3dxgpidbssnn3qjp@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Hi, this patch makes aliasing_component_refs_p little bit stronger, especially with LTO increasing number of disambiguations on tramp3d by 2%. It took me a while to uderstand that function so a bit summary what it does. Function analyzes chains of nested references like ref1: a.b.c.d.e ref2: c.d.f (Here I assume that type of a is a and type of b is b etc.) On such chains it looks for outermost common type (c) and then compares accesss c.d.e and c.d.f for range overlap. This is safe because we know that both copies of type c are either overlaping or completely different. Walk is done in both directions so ref1: c.d.f ref2: a.b.c.d.e Gives the same answer. In the final step it is assumed that the reference chains do not have common type and may reference one to another only if one is continuation of the other (with some intermediate steps omitted). So function is organized as follows 1) perform walk of ref1 looking for type of base of ref2. If we sucessful use base+offset oracle. 2) perform walk of ref2 looking for type of base of ref1 If we sucessful use base+offset oracle. 3) assume that chains are disjoiont and see of base type of one is subset of ref type of the other (i.e. one can be can be a continuation of the chain). Now same_type_for_tbaa can return -1 for some odd cases which include the case where TYPE_CANONICAL==NULL the function gives up. This is quite common with LTO because TYPE_CANONICAL is NULL for pointers, vectors and arrays and thus we often give up after the innermost reference. If the first walk in 1) terminates with -1 then it still makes sense to do the walk in 2) and see if the common type is found. If there is no common type we need to give up on the final test. I wonder if as an optimization we do not want to terminate the walk when one type is too small to hold the second. Bootstrapped/regtested x86_64-linux, OK? * tree-ssa-alias.c (aliasing_component_refs_p): Walk references both directions even if first walk fails. Index: tree-ssa-alias.c =================================================================== --- tree-ssa-alias.c (revision 270877) +++ tree-ssa-alias.c (working copy) @@ -814,10 +841,7 @@ aliasing_component_refs_p (tree ref1, && same_type_for_tbaa (TREE_TYPE (*refp), type1) == 0) refp = &TREE_OPERAND (*refp, 0); same_p = same_type_for_tbaa (TREE_TYPE (*refp), type1); - /* If we couldn't compare types we have to bail out. */ - if (same_p == -1) - return true; - else if (same_p == 1) + if (same_p == 1) { poly_int64 offadj, sztmp, msztmp; bool reverse; @@ -827,24 +851,31 @@ aliasing_component_refs_p (tree ref1, offset1 -= offadj; return ranges_maybe_overlap_p (offset1, max_size1, offset2, max_size2); } - /* If we didn't find a common base, try the other way around. */ - refp = &ref1; - while (handled_component_p (*refp) - && same_type_for_tbaa (TREE_TYPE (*refp), type2) == 0) - refp = &TREE_OPERAND (*refp, 0); - same_p = same_type_for_tbaa (TREE_TYPE (*refp), type2); - /* If we couldn't compare types we have to bail out. */ - if (same_p == -1) - return true; - else if (same_p == 1) + else { - poly_int64 offadj, sztmp, msztmp; - bool reverse; - get_ref_base_and_extent (*refp, &offadj, &sztmp, &msztmp, &reverse); - offset1 -= offadj; - get_ref_base_and_extent (base2, &offadj, &sztmp, &msztmp, &reverse); - offset2 -= offadj; - return ranges_maybe_overlap_p (offset1, max_size1, offset2, max_size2); + int same_p2; + + /* If we didn't find a common base, try the other way around. */ + refp = &ref1; + while (handled_component_p (*refp) + && same_type_for_tbaa (TREE_TYPE (*refp), type2) == 0) + refp = &TREE_OPERAND (*refp, 0); + same_p2 = same_type_for_tbaa (TREE_TYPE (*refp), type2); + if (same_p2 == 1) + { + poly_int64 offadj, sztmp, msztmp; + bool reverse; + get_ref_base_and_extent (*refp, &offadj, &sztmp, &msztmp, &reverse); + offset1 -= offadj; + get_ref_base_and_extent (base2, &offadj, &sztmp, &msztmp, &reverse); + offset2 -= offadj; + return ranges_maybe_overlap_p (offset1, max_size1, + offset2, max_size2); + } + /* In the remaining test we assume that there is no overlapping type + at all. So if we are unsure, we need to give up. */ + else if (same_p == -1 || same_p2 == -1) + return true; } /* If we have two type access paths B1.path1 and B2.path2 they may