From patchwork Tue Sep 29 06:45:23 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: 523734 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 1ACB51400A0 for ; Tue, 29 Sep 2015 16:46:04 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=RH/LxYB5; 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:content-transfer-encoding; q=dns; s= default; b=toPJcU6XWTfcl0fbhh0UiQgQeFraZzxN0wNYuiIY8l8x5K1CMHZHW eON0uhwt4tfWTlHCkKQG3PoclmYifMqNg5/I8BQtC7IICgydrAI0wu7frU5VFL7Z V0JGxGIYfdvbTrANbWI4gDOTavO5NC/FmzSY7z3e8pt7Rqyv28l8YY= 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:content-transfer-encoding; s=default; bh=57XYlYH+RVFFmilMMKCh2xLfwRM=; b=RH/LxYB59pH+mfmkFJzRizuMZR3Z ZAKdJ2Fa6mB2uxuGygOgGmsoBDSjMYsqWJASiyigh7/o7Hd7yVzT58HDesW6HZPl UvmAPN0UAXRdp8BM8j/FZHTMabXRVewBAyACSUcKB9/kkTBK7Mi9j0i0vkP24RdA X+O467AMZOmPU5E= Received: (qmail 56029 invoked by alias); 29 Sep 2015 06:45:58 -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 56016 invoked by uid 89); 29 Sep 2015 06:45:58 -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, SPF_PASS, T_RP_MATCHES_RCVD 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; Tue, 29 Sep 2015 06:45:57 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40274) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Zgofi-0004Mp-Lv for gcc-patches@gnu.org; Tue, 29 Sep 2015 02:45:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgoff-0000WO-2Y for gcc-patches@gnu.org; Tue, 29 Sep 2015 02:45:54 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:57342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgofe-0000W1-Tv for gcc-patches@gnu.org; Tue, 29 Sep 2015 02:45:51 -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 1Zgofd-0007V0-3y from Tom_deVries@mentor.com ; Mon, 28 Sep 2015 23:45:49 -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; Tue, 29 Sep 2015 07:45:47 +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> CC: "gcc-patches@gnu.org" From: Tom de Vries Message-ID: <560A3383.3020608@mentor.com> Date: Tue, 29 Sep 2015 08:45:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.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 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. Thanks, - Tom if (i + 1 < fieldstack.length ()) diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c index 8d86dcb..26d97a3 100644 --- a/gcc/tree-ssa-structalias.c +++ b/gcc/tree-ssa-structalias.c @@ -5720,6 +5720,8 @@ create_variable_info_for_1 (tree decl, const char *name) newvi->offset = fo->offset; newvi->size = fo->size; newvi->fullsize = vi->fullsize; + if (fieldstack.length () == 1) + newvi->is_full_var = true; newvi->may_have_pointers = fo->may_have_pointers; newvi->only_restrict_pointers = fo->only_restrict_pointers;