From patchwork Fri Oct 23 09:55:32 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 534885 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 96611141332 for ; Fri, 23 Oct 2015 20:56:01 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=YIBMEvNy; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=YQdWBfKkWR2b4SrIQ LwnfzVR4FLu7Xd4gO1YXyGGHwEredKF3umnY1kB0X93x7GyFK2aTJFiIceDVcGCj 0wljRTwfrgVcMSi/+waVM71SN1UeyRKOI5yAvBaYos0x37Kd0jqot2CCBs9VqdZn YVouCfcXfqB7mLkGuo6Y+dbSf8= 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 :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=oHpb1JTK8KFBMvGHB1b1Xax 8VeA=; b=YIBMEvNyRMiBg6hhct1CW/sGgGnadg9bc/hPX4kG/eyToc27eH6j2xy u6mNo7cP5gaMOIkBe7zgnxvh2ZVAfHEbiLLVEJrY60qPB136FXO6nYqR/oHRB/ly o/q6JlZ+8d07mcTTdZCxXtfZRvU4Pw2VK9Vd+VlCeYJIiCbfu8QM= Received: (qmail 83382 invoked by alias); 23 Oct 2015 09:55: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 83365 invoked by uid 89); 23 Oct 2015 09:55:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 23 Oct 2015 09:55:52 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48935) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZpZ4g-0008Un-1N for gcc-patches@gnu.org; Fri, 23 Oct 2015 05:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpZ4b-0004YM-EQ for gcc-patches@gnu.org; Fri, 23 Oct 2015 05:55:49 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:35938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpZ4b-0004Y5-6f for gcc-patches@gnu.org; Fri, 23 Oct 2015 05:55:45 -0400 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZpZ4Z-0002nX-Pz from Tom_deVries@mentor.com ; Fri, 23 Oct 2015 02:55:44 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Fri, 23 Oct 2015 10:55:42 +0100 Subject: Re: [PATCH][PR67666] Handle single restrict pointer in struct in create_variable_info_for_1 To: Richard Biener References: <5600FBFA.2090300@mentor.com> <560A3383.3020608@mentor.com> CC: "gcc-patches@gnu.org" From: Tom de Vries Message-ID: <562A0414.2040602@mentor.com> Date: Fri, 23 Oct 2015 11:55:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 On 29/09/15 10:29, Richard Biener wrote: > On Tue, 29 Sep 2015, Tom de Vries wrote: > >> On 22/09/15 09:49, Richard Biener wrote: >>> On Tue, 22 Sep 2015, Tom de Vries wrote: >>> >>>> Hi, >>>> >>>> Consider this test-case: >>>> >>>> struct ps >>>> { >>>> int *__restrict__ p; >>>> }; >>>> >>>> void >>>> f (struct ps &__restrict__ ps1) >>>> { >>>> *(ps1.p) = 1; >>>> } >>>> >>>> >>>> Atm, the restrict on p has no effect. Now, say we add a field to the >>>> struct: >>>> >>>> struct ps >>>> { >>>> int *__restrict__ p; >>>> int a; >>>> }; >>>> >>>> >>>> Then the restrict on p does have the desired effect. >>>> >>>> >>>> This patch fixes the handling of structs with a single field in alias >>>> analysis. >>>> >>>> Bootstrapped and reg-tested on x86_64. >>>> >>>> OK for trunk? >>> >>> Ok. >>> >> >> Hi, >> >> I wonder if this follow-up patch is necessary. >> >> Now that we handle structs with one field in the final loop of >> create_variable_info_for_1, should we set the is_full_var field as well? It >> used to be set for such structs before I committed the "Handle single restrict >> pointer in struct in create_variable_info_for_1" patch. > > Yeah, I suppose so. But I'd set vi->is_full_var to true when > allocating 'vi': > > vi = new_var_info (decl, name); > vi->fullsize = tree_to_uhwi (declsize); > + if (fieldstack.length () == 1) > + vi->is_full_var = true; > > > Ok with that change. > Committed as attached. Thanks, - Tom Add missing is_full_var setting in create_variable_info_for_1 2015-10-23 Tom de Vries * tree-ssa-structalias.c (create_variable_info_for_1): Add missing setting of is_full_var in case of a single field. --- gcc/tree-ssa-structalias.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c index 8d86dcb..db0ab1e 100644 --- a/gcc/tree-ssa-structalias.c +++ b/gcc/tree-ssa-structalias.c @@ -5693,6 +5693,8 @@ create_variable_info_for_1 (tree decl, const char *name) vi = new_var_info (decl, name); vi->fullsize = tree_to_uhwi (declsize); + if (fieldstack.length () == 1) + vi->is_full_var = true; for (i = 0, newvi = vi; fieldstack.iterate (i, &fo); ++i, newvi = vi_next (newvi)) -- 1.9.1